SVT TERM END NOTES

Auditing Variable Use –

1. Variables are just storage boxes

"Variables are objects used to store data elements that have some relevance to an
application."
Imagine you are running a coffee shop. You have a box labeled Customer_Age, a box
labeled Coffee_Price, and a box labeled Quantity_Ordered. These boxes store the
numbers you need to run your business.
2. The box only matters because of what you do with it
"They are given meaning by the way they're used: what's stored in them, what
operations are performed on them, and what they represent."
A number 5 sitting in a box means nothing on its own.
 If 5 is in the Coffee_Price box, it means a coffee costs $5.
 If 5 is in the Quantity_Ordered box, it means the customer wants 5 coffees.
The meaning comes from how the app uses that box later (e.g., multiplying them
together to get a total bill).
3. Variables depend on each other (Relationships)
"...understanding variables, their relationships to each other..."
In our coffee shop app, there is a relationship:
Total_Bill = Coffee_Price × Quantity_Ordered
4. The "Unexpected Manipulation" (The Hack)
"...and how an application can be affected adversely by unexpected manipulation of
these relationships."
This is the most important part. Programmers usually expect normal behavior. They
expect a customer to type 2 into the Quantity_Ordered box. The total bill becomes $10.
Everything works perfectly.
But what if a malicious hacker comes along and types -100 (negative one hundred)
into the Quantity_Ordered box?
If the programmer didn't write code to stop negative numbers, the app does the math
exactly as told:
$5× -100 = -$500
Suddenly, the Total_Bill is negative $500. The application's logic is broken, and the
checkout system might think the coffee shop owes the hacker $500.
Summary: What is "Auditing Variable Use"?
Auditing Variable Use is simply acting like a detective, looking at all the "boxes" in
a computer program, and asking:
 "What is supposed to go in this box?" * "What happens if I put something
totally weird or unexpected in this box?" * "Will it break the app or let me steal
data?"
Structure and Object Mismanagement –
Let's look at this purely through the lens of a video game glitch.
In video games, "Structure Mismanagement" (or an inconsistent state) is usually how
players discover invincibility glitches.
The Setup: Two Variables That Must Match
Imagine you are programming a character in a game. The character is a single
"Object" that has two variables:
1. Health (Starts at 100)
2. Is_Alive (Starts as True)
The Golden Rule (Synchronization)
The game's code has a strict rule: If Health reaches 0, Is_Alive MUST immediately
change to False. They are connected. They must stay synchronized.
The Hack (Inconsistent State)
An auditor (or a gamer looking for exploits) wants to break this rule. They want to
create an inconsistent state where the variables contradict each other.
Imagine the player drinks a health potion at the exact same millisecond they get hit
by a lethal attack.
Because of a flaw in the code, the game gets confused. The attack successfully
drops the Health to 0, but the potion animation interrupts the code before it can
change Is_Alive to False.
The Result: The Game Breaks
Look at the character's variables now:
 Health = 0
 Is_Alive = True
This is Structure Mismanagement. The variables are out of sync.
The game is now completely broken. The enemy AI stops attacking because your
health is 0 (so you must be dead), but you can still run around and shoot because
Is_Alive is True. You are a zombie. You have unlocked invincibility.
Why Auditors Care
When auditing code, security professionals are looking for exactly this. They look for
ways to interrupt the program so that Variable A changes, but Variable B doesn't,
causing the system to unlock doors, bypass passwords, or give you invincibility.
Here is a quick interactive simulation. Try playing normally, and then try triggering
the glitch to see exactly how "Inconsistent State" breaks the rules.

Arithmetic Boundaries -
This concept is referring to a vulnerability known as an Integer Overflow (or
Underflow).
To explain this simply: Variables in a computer are not infinite boxes. They have
strict physical size limits determined by their "data type."
Think of a variable like a mechanical car odometer that only has 5 digits. The
maximum number it can hold is 99,999.
 What happens if you drive one more mile?
 It doesn't go to 100,000. It physically runs out of space, "wraps around" the
boundary, and clicks back to 00,000.
In programming, this is an Arithmetic Boundary Wrap.
Here is the formal translation of the auditing process you provided:
The Vulnerability: Bypassing Checks via Wrapping
Security checks usually rely on math. For example, a system might say:
 "If the requested file size is less than 200 bytes, approve the upload."
If a hacker requests a file size of 260 bytes, the system should block it. However, if
the variable holding that number has a maximum limit of 255 (an 8-bit integer), the
math "wraps around." The system calculates 260, it overflows, and becomes 4.
The security check sees 4, which is less than 200, and approves the upload. The
hacker successfully bypassed the rule.
The Auditor's Checklist (Translated)
When the text gives you that list of steps, it is giving you a detective's roadmap for
finding this exact exploit. Here is what those steps actually mean:
1. Find the Target: Look for critical math operations (like calculating memory
sizes or password lengths). "If this math wraps around, could a hacker bypass
a security check?"
2. Find the Trigger: Do the math yourself. "Exactly what massive number do I
need to input to make this variable wrap around to a small, safe-looking
number?"
3. Trace the Path: "Can I actually send that massive number into the
application from the outside, or will the app block it before it reaches the
vulnerable math?"
4. Identify Data Type: "Is this an 8-bit variable (max 255), a 16-bit variable
(max 65,535), or something else?" (This tells you what the wrap boundary is).
5. Trace the Variables (Steps 5, 6, 7): Track the variable from the moment the
user types it in, through every assignment and if/then constraint in the code,
all the way to the vulnerable math operation. Ensure no other code
accidentally fixes or blocks your malicious "wrap" number.
Summary
Auditing arithmetic boundaries means finding places where a variable's maximum
size limit can be exceeded, causing the number to wrap around to zero or a negative
number, effectively tricking the system's security logic into approving something it
shouldn't.

Type Confusion –
Let's try a completely different approach. Let's forget the C++ code and the jargon for
a minute.
At its core, Type Confusion is a translation error.
Imagine computer memory is just a giant whiteboard filled with raw 1s and 0s. The
memory itself has no idea what it is holding. It's just blank, raw data.
A "Type" (like an Integer, a String of text, or an Object) is simply the rulebook or lens
the computer uses to read that whiteboard.
 If you write the letters H I ! on the whiteboard, and tell the computer, "Read
this using the Text rulebook," it reads "HI!" and everything works perfectly.
 But what if you leave H I ! on the whiteboard, and tell the computer, "Read
this using the Integer (Numbers) rulebook"?
The computer doesn't know any better. It blindly applies the math rulebook to the
letters. It crunches the binary code for those letters and spits out a giant, nonsensical
number (like 1210458368).
That is Type Confusion: The data in memory is one thing, but the program is tricked
into reading it as something else.
It gets extremely dangerous when the computer thinks a random number is actually
a set of instructions (an Object) and tries to execute it, which usually causes the
program to crash or gives a hacker control.
I've built a "Memory Lens" simulator below. Try writing data into the raw memory,
and then try reading it back using the wrong lens to see exactly how Type Confusion
happens!
Show me the visualisation
Does seeing how the computer blindly translates the raw bytes make the idea of
"Type Confusion" clearer, or should we look at how hackers actually exploit this in
the real world?
🧠 Lists and Tables (Linked Lists &
Hash Tables)
👉 These are data structures used to:
 Store multiple values
 Easily add, delete, search data
Examples:
 Linked List
 Hash Table

⚠️Main Idea (VERY IMPORTANT)

👉 While coding these structures, small mistakes can break everything
👉 Result:
 Wrong data
 Crashes
 Security vulnerabilities

🔍 Common Problems (Explained Simply)

1️⃣ Empty List Handling

❌ Problem:
Program doesn’t check if list is empty
head = NULL;
head->next; // ❌ crash
💥 Result:
 Segmentation fault
 Program crash
✅ Fix:
Always check:
if (head == NULL)
2️⃣ Duplicate Elements
❌ Problem:
Same data appears multiple times
Example:
 Two users with same ID
 Two sessions with same cookie
💥 Result:
 Wrong element selected
 Data confusion
 Possible security issues

3️⃣ Incorrect Pointer Updates (VERY IMPORTANT)

👉 In doubly linked list:
A <-> B <-> C
If deleting B:
✅ Correct:
A <-> C
❌ If wrong:
 A still points to B
 C still points to B
💥 Result:
 Broken links
 Invalid memory access

4️⃣ Data Range Issues

❌ Problem:
Wrong or invalid data ranges
Examples:
 Overlapping memory ranges
 Zero-length data
 Invalid values
💥 Result:
  Incorrect processing
 Unexpected behavior

5️⃣ Head and Tail Pointer Issues

👉 Important variables:
 head → start of list
 tail → end of list

❌ Problem:
Not updating them properly
Example:
[10] <-> [20] <-> [30]
Delete 10:
 Correct → head = 20
 Wrong → head still points to 10 ❌

💥 Result:
 Accessing deleted memory
 Crash or undefined behavior

🔥 Why this is dangerous (Security View)

👉 If attacker finds these bugs:
 Can force program to use invalid memory
 Can cause:
o Crashes
o Memory corruption
o Data leaks

🧾 Simple Real-Life Analogy

👉 Think of a linked list like a train:
 Each coach = node
 Connections = pointers
If connections break:
  Train becomes disconnected 🚂❌
 System fails

🔑 Final Summary (Easy to Remember)

👉 Problems happen when:
 Empty list not handled
 Duplicate data exists
 Pointers not updated
 Head/tail not updated
 Data not validated

🧠 One-line memory trick:

👉 “Check empty, avoid duplicates, fix pointers, update head/tail, validate data.”

If you want, I can give:

👉 C++ code examples showing correct vs incorrect implementation (very
helpful for exams)

🧠 Empty List Vulnerability (Simple +

Detailed)
🔹 What is it?
👉 Empty List Vulnerability happens when a program does not correctly handle
cases where the list becomes empty.

🔍 Basic Idea
In a linked list, we use:
 head → first element
 tail → last element
👉 When all elements are deleted, the list should become:
head = NULL
tail = NULL

❌ Where the problem occurs

When deleting elements, especially:
 First node
 Last node
 Only node
👉 If head or tail is not updated correctly, the list becomes invalid

💥 Example (VERY IMPORTANT)

Initial list:
[10]
👉 Only one node:
 head → 10
 tail → 10

Now delete 10:

✅ Correct behavior:
head = NULL
tail = NULL

❌ Wrong behavior (VULNERABILITY):

head → still points to deleted memory ❌
tail → still points to deleted memory ❌

💣 What happens then?

 Program thinks list is not empty
 But actually memory is freed
👉 So:
 Accessing head->data → 💥 crash
 Using list → undefined behavior
🔥 Another Case (from PPT logic)
When deleting head in multi-node list:
[10] <-> [20] <-> [30]
Delete 10:
❌ If not handled:
 head still points to 10 (deleted)
💥 Result:
 Invalid memory access
 Crash / wrong data

⚠️Why it's dangerous (Security View)

👉 Attacker can:
 Force program to use freed memory
 Trigger:
o Crashes
o Memory corruption
o Unexpected behavior

✅ Correct Handling (Important for exam)

Always handle these cases:
if (head == NULL) {
// list is empty
}
And after deletion:
if (head == NULL) {
tail = NULL;
}

🔑 Final One-Line (Exam Ready)

👉 Empty List Vulnerability occurs when a program fails to correctly update
head/tail after deletion, causing access to invalid or freed memory.
If you want, I can next explain:
👉 Duplicate Elements vulnerability from your PPT (same style)

🧠 Duplicate Elements Vulnerability

🔹 Definition (Write this in exam)
👉 Duplicate Elements Vulnerability occurs when a data structure (like a linked
list or hash table) allows multiple elements with the same key/value, leading to
confusion, incorrect behavior, or security issues.

🔍 Basic Idea
In many applications, data structures store elements using a unique identifier
(key).
Examples:
 User ID
 Session ID (cookies)
 Account number
👉 These values are expected to be unique

❌ Problem
If duplicates are allowed:
 Two or more elements have the same key
 System cannot clearly identify the correct one

💥 How the vulnerability occurs

Example (Linked List)
[UserID=101] <-> [UserID=102] <-> [UserID=101]
👉 Here, UserID=101 appears twice

🔥 What goes wrong?

When program searches:
find(UserID=101);
👉 It may:
 Return first element OR
 Return second element
👉 Behavior becomes unpredictable

⚠️Real-World Security Example (VERY IMPORTANT)

👉 Consider web sessions (cookies)
 Each user has a unique session ID
 Server stores sessions in a list/table
❌ If duplicate session IDs exist:
Session A → User 1
Session A → User 2
👉 System may:
 Mix sessions
 Give access of User 1 to User 2
💣 Result:
 Information leak
 Unauthorized access
 Privilege escalation

🧩 Why this happens (Theory Point)

Duplicate elements occur due to:
 No validation while inserting data
 Poor design of data structures
 Missing uniqueness checks
 Incorrect hashing or collision handling

💣 Impact of Duplicate Elements

👉 Leads to:
1. Wrong Data Retrieval
o System selects incorrect element
 2. Data Confusion
o Two elements treated as one
3. Security Issues
o Session hijacking
o Unauthorized access
4. Logic Errors
o Incorrect program behavior

🔧 Example in C (Simple)
struct User {
int id;
};

User list[3] = { {101}, {102}, {101} }; // duplicate

👉 Searching for 101 → ambiguous result ❌

✅ Prevention (Important for exam)

To avoid this vulnerability:
 Ensure unique keys
 Validate before insertion:
if (already_exists(key)) {
reject();
}
 Use proper data structures (like hash tables with collision handling)
 Implement checks for duplicates

🔑 Final One-Line (Exam Ready)

👉 Duplicate Elements Vulnerability occurs when non-unique keys exist in a
data structure, causing ambiguity, incorrect behavior, and potential security
risks like unauthorized access.

🧠 Quick Revision Points

 Same key appears multiple times ❌
  Causes confusion in search
 Can lead to security issues
 Prevent by enforcing uniqueness

If you want, next I can explain:

👉 Previous & Next Pointer Update vulnerability (VERY important + tricky)

Perfect — this is one of the most important and tricky topics. I’ll explain it in a
10-mark answer format (simple + detailed + exam-ready) 👇

🧠 Previous & Next Pointer Update

Vulnerability
🔹 Definition (Write this in exam)
👉 Previous & Next Pointer Update Vulnerability occurs when the pointers
connecting nodes in a linked list are not updated correctly during insertion or
deletion, leading to broken links, invalid memory access, or corrupted data
structures.

🔍 Basic Idea
In a doubly linked list, each node has:
struct Node {
int data;
struct Node *prev;
struct Node *next;
};
👉 So every node is connected like:
A <-> B <-> C
 [Link] = B
 [Link] = A
 [Link] = C
 [Link] = B
⚠️Where the problem happens
👉 When performing operations like:
 Deletion
 Insertion
👉 If both pointers are not updated correctly, the list becomes inconsistent

💥 Example (Deletion Case)

Initial list:
A <-> B <-> C
Delete node B

✅ Correct Update:
A <-> C
A->next = C;
C->prev = A;

❌ Incorrect Update (Vulnerability):

If programmer forgets:
A->next = C;
// but forgets:
C->prev = A; // ❌ missing
👉 Now structure becomes:
A→C
C → still points to B ❌

💣 What goes wrong

1. Broken Links
o List traversal fails
2. Dangling Pointers
o Still pointing to deleted node
3. Invalid Memory Access
 o Accessing freed memory
4. Crash / Undefined Behavior
o Program may crash

🔥 Security Impact (VERY IMPORTANT)

👉 If attacker exploits this:
 Can force program to use invalid pointers
 May lead to:
o Memory corruption
o Data leaks
o Arbitrary code execution (advanced cases)

🧩 Why this happens

 Programmer forgets to update both pointers
 Incorrect order of operations
 Poor handling of edge cases (first/last node)

⚠️Special Cases to Handle

👉 Must be careful when:
 Deleting first node (head)
 Deleting last node (tail)
 Deleting only node

🔧 Correct Safe Approach

Always update BOTH sides:
if (node->prev != NULL)
node->prev->next = node->next;

if (node->next != NULL)
node->next->prev = node->prev;

🧾 Real-Life Analogy
👉 Think of it like people holding hands:
A—B—C
If B leaves:
 A should hold C
 C should hold A
👉 If one side forgets → chain breaks ❌

🔑 Final One-Line (Exam Ready)

👉 This vulnerability occurs when both previous and next pointers are not
properly updated, causing broken links, dangling pointers, and potential
memory corruption.

🧠 Quick Revision Points

 Happens in linked lists
 Caused by incorrect pointer updates
 Leads to broken structure
 Can cause crashes or security issues

If you want next, I can explain:

👉 Data Range Vulnerability (last topic in this section, also important)

Great — this is the last key concept in this section, and I’ll explain it in a 10-
mark, exam-ready way (simple + detailed) 👇

🧠 Data Range Vulnerability

🔹 Definition (Write this in exam)
👉 Data Range Vulnerability occurs when a program fails to properly validate or
handle the range (size, boundaries, or limits) of input data, leading to incorrect
behavior, memory errors, or security issues.

🔍 Basic Idea
👉 Every data has a valid range
Examples:
 Array index → 0 to n-1
 Buffer size → limited length
 Memory range → fixed boundaries
👉 If program does not check these limits ❌
👉 Data may go out of range

⚠️Types of Data Range Issues

1️⃣ Out-of-Bounds Access

❌ Example:
int arr[5];
arr[10] = 100; // ❌ out of range
💥 Result:
 Access invalid memory
 Crash or corruption

2️⃣ Overlapping Data Ranges

👉 Two data regions overlap incorrectly
❌ Example:
Range1: 100–200
Range2: 150–250 ❌ overlap
💥 Result:
 Data corruption
 Wrong processing

3️⃣ Duplicate Data Ranges

👉 Same range used multiple times
💥 Result:
 Confusion in selection
 Wrong data returned

4️⃣ Zero-Length Data

❌ Example:
malloc(0); // risky
💥 Result:
 Undefined behavior
 May cause logic errors

5️⃣ Invalid Input Size

❌ Example:
char buf[10];
strcpy(buf, input); // no size check ❌
💥 Result:
 Buffer overflow
 Memory corruption

💣 Why it is dangerous (Security View)

👉 Attackers exploit range issues to:
 Access memory they shouldn’t
 Overwrite data
 Cause crashes
 Execute malicious code

🔑 Final One-Line (Exam Ready)

👉 Data Range Vulnerability occurs when input values exceed or violate defined
limits, leading to memory corruption, incorrect behavior, or security risks.
🧠 Linux Teardrop Vulnerability
🔹 Definition (Write this in exam)
👉 Teardrop Vulnerability is a denial-of-service (DoS) attack that exploits
improper handling of overlapping IP packet fragments, causing the system to
crash or behave unpredictably.

🔍 Basic Idea
👉 In networking, large data is broken into smaller packets (fragments) before
sending.
Each fragment contains:
 Offset (position of data)
 Length
👉 Receiver system reassembles them to form original data

📦 Normal Fragmentation
Packet 1 → offset 0, length 100
Packet 2 → offset 100, length 100
👉 No overlap → works fine ✅

❌ What attacker does (Teardrop Attack)

👉 Sends malformed overlapping packets
Packet 1 → offset 0, length 100
Packet 2 → offset 80, length 100 ❌ overlap
👉 Now:
 Data overlaps between 80–100

💥 What goes wrong

👉 Old Linux systems could not handle this properly
 While reassembling:
o System gets confused
o Tries to merge overlapping data
💣 Result:
 Memory corruption
  System crash
 Kernel panic

🔥 Why called “Teardrop”

👉 Because packets are broken into pieces like tears, but incorrectly formed

⚠️Impact
 Denial of Service (DoS)
 System becomes unusable
 Network services stop

🧩 Why vulnerability occurs

 Improper validation of packet fragments
 No checks for overlapping ranges
 Weak handling of edge cases

🔑 Final One-Line (Exam Ready)

👉 Linux Teardrop Vulnerability exploits overlapping IP fragments to crash a
system by confusing the packet reassembly process.

🧠 Looping Construct Vulnerability

🔹 Definition (Write this in exam)
👉 Looping Construct Vulnerability occurs when loops (for, while, do-while) are
implemented incorrectly, causing unintended behavior such as infinite loops,
out-of-bounds access, or incorrect data processing.

🔍 Basic Idea
👉 Loops are used to:
 Process arrays
 Read/write data
 Repeat operations
👉 If loop conditions or logic are wrong ❌
👉 It can lead to serious bugs and security issues
⚠️Common Looping Errors (VERY IMPORTANT)

1️⃣ Incorrect Termination Condition

❌ Example:
for (int i = 0; i <= 10; i++) // ❌ should be < 10
👉 Accesses:
 arr[10] (out of bounds)
💥 Result:
 Memory corruption
 Crash

2️⃣ Missing Boundary Checks

❌ Example:
while (input[i] != '\0') {
buffer[i] = input[i];
i++;
}
👉 No check on buffer size ❌
💣 Result:
 Buffer overflow

3️⃣ Infinite Loop

❌ Example:
while (1) {
// no break condition ❌
}
💥 Result:
 CPU usage 100%
 Program hangs (DoS)

4️⃣ Wrong Loop Type (Post-test vs Pre-test)

❌ Example:
do {
process(data);
} while (condition);
👉 Runs at least once even if condition is false ❌
💥 Result:
 Unexpected execution

5️⃣ Missing or Misplaced break / continue

❌ Example:
for (int i = 0; i < n; i++) {
if (arr[i] == target)
continue; // ❌ skips important logic
}
💥 Result:
 Wrong processing
 Logic errors

6️⃣ Syntax / Logical Mistakes

❌ Example:
for (int i = 0; i < n; i++); // ❌ semicolon ends loop
{
process(i);
}
💥 Result:
 Loop does nothing
 Code runs incorrectly

💣 Why it is dangerous (Security View)

👉 Attackers can exploit loop bugs to:
 Cause buffer overflow
 Trigger infinite loops (DoS attack)
  Access invalid memory

🧩 Why this happens

 Incorrect condition checks
 Ignoring boundary limits
 Poor understanding of loop behavior
 Missing edge case handling

🔑 Final One-Line (Exam Ready)

👉 Looping Construct Vulnerability occurs due to incorrect loop logic or
boundary conditions, leading to issues like buffer overflow, infinite loops, or
incorrect program behavior.

Unbound vs. Bound String Functions -

Here is the direct, technical explanation of Unbound vs. Bound String Functions, focusing on how
they handle memory.

In languages like C and C++, memory for text (strings) is manually reserved in fixed-size blocks called
buffers. For example, you might reserve exactly 8 bytes to hold a password. The vulnerability
depends on which function you use to copy data into that 8-byte space.

1. Unbound Functions (The Blind Copier)

 Examples: gets(), strcpy(), strcat()

 How they work: These functions do not ask how big the destination buffer is. They just start
copying data and only stop when they see a special invisible character called a null
terminator (\0), which marks the end of a string.

 The Vulnerability (Buffer Overflow): If an attacker inputs a 100-character string into your 8-
byte buffer, an unbound function will blindly copy all 100 characters. It fills your 8 bytes, and
then overwrites the next 92 bytes of adjacent computer memory. This crashes the program
or allows the attacker to overwrite actual executable code to hijack the system.

2. Bound Functions (The Strict Copier)

 Examples: fgets(), strncpy(), strncat()

  How they work: These functions force the developer to declare a hard limit. You tell the
function: "Copy this string, but NEVER copy more than 8 characters."

 The Security: Even if an attacker sends 100 characters, the function stops exactly at the 8th
character. The adjacent memory is safe, and the overflow is prevented.

3. The "Gotcha" with Bound Functions

While safer, bound functions have a known flaw. If the attacker sends exactly 8 or more characters, a
function like strncpy() will fill all 8 bytes but might fail to add the \0 (null terminator) at the end.

Later, if the program tries to read that string, it won't know where it ends. It will keep reading past
the buffer into adjacent memory, causing a different vulnerability called an Out-of-Bounds Read.

Here are clear, exam-ready answers with explanations 👇

Q1. Big Endian vs Little Endian

We are storing:
0x12345678 (32-bit = 4 bytes)
Break into bytes:
0x12 0x34 0x56 0x78
🔹 Big Endian (MSB stored first)
Address Value

100 0x12

101 0x34

102 0x56

103 0x78
👉 Explanation:
Big Endian stores the Most Significant Byte (MSB) at the smallest memory
address.
🔹 Little Endian (LSB stored first)
Address Value

100 0x78

101 0x56

102 0x34

103 0x12
👉 Explanation:
Little Endian stores the Least Significant Byte (LSB) first.

Q2. Memory Allocation (First-fit, Best-fit, Worst-fit)

Memory Blocks:
100K, 500K, 200K, 300K, 600K
Processes:
212K, 417K, 112K, 624K

🔹 First-Fit
 212K → 500K (first sufficient)
 417K → 600K
 112K → 200K
 624K → ❌ Not allocated

🔹 Best-Fit (smallest sufficient block)

 212K → 300K
 417K → 500K
 112K → 200K
 624K → ❌ Not allocated

🔹 Worst-Fit (largest block)

 212K → 600K
  417K → 500K
 112K → 300K
 624K → ❌ Not allocated

✅ Most Efficient?
👉 Best-Fit is generally most efficient because:
 Minimizes leftover (internal fragmentation)
 Uses smallest suitable block
⚠️But in real systems:
 Can cause external fragmentation over time

Q3. String Vulnerabilities (Code Example)

🔴 Example: Buffer Overflow
#include <stdio.h>
#include <string.h>

int main() {
char buffer[10];

printf("Enter input: ");

gets(buffer); // ❌ Dangerous function

printf("You entered: %s\n", buffer);

return 0;
}

⚠️Problem:
 gets() does no bounds checking
 If user enters >10 chars → buffer overflow
 Can overwrite:
 o Return address
o Stack memory

🔥 Attack Impact:
 Crash program
 Execute malicious code

✅ Secure Version:
fgets(buffer, sizeof(buffer), stdin);

🔴 Another Example: Format String Vulnerability

printf(user_input); // ❌ Dangerous
Attacker input:
%x %x %x
👉 Can leak memory data

Q4. Email Header Injection using Meta-Characters

🔴 What are Meta-Characters?
Special characters like:
\n (newline)
\r (carriage return)

🔥 Vulnerable Code Example (PHP-like logic)

$to = $_POST['email'];
$subject = $_POST['subject'];

mail($to, $subject, "Hello");

⚠️Attack Input:
victim@[Link]
\nBcc: attacker@[Link]

💣 Result:
Actual email header becomes:
To: victim@[Link]
Bcc: attacker@[Link]
👉 Attacker secretly receives email

🚨 Real-World Impact:
 Mass spam/phishing emails
 Data leakage
 Email spoofing

Prevention:
 Validate input strictly
 Remove meta-characters:
$input = str_replace(["\r", "\n"], '', $input);
 Use secure email libraries

✅ Final Summary
Question Key Concept

Q1 Byte ordering (Endianness)

Q2 Memory allocation strategies

Q3 Buffer overflow & format string vulnerabilities

Q4 Email header injection via meta-characters

If you want, I can convert this into perfect handwritten-style notes / PDF for
exams or give MCQs based on this.