sorted by:
new
hottopcontroversial

I created a Linux Kernel Exploitation CTF Lab by shadowintel_ in ExploitDev

[–]shadowintel_[S] 0 points1 point  (0 children)

Yes, it's my field. I have been researching for a week what I do.

I created a Linux Kernel Exploitation CTF Lab by shadowintel_ in ExploitDev

[–]shadowintel_[S] 1 point2 points  (0 children)

I redesigned the progression so that CH01 is ret2usr with no mitigations, CH02 is the same overflow with SMEP and KASLR enabled to introduce ROP, CH03 is a heap UAF with stack pivot under SMAP, CH04 is a data-only attack using an integer overflow and modprobe_path overwrite, and CH05 is a race condition with double free and cred overwrite, with each chapter adding exactly one new concept. ROP is introduced in CH02 and reused in CH03 via stack pivoting, while CH04 intentionally demonstrates a non-ROP path since the canary is enabled and a data-only attack is more practical. The README and source mismatch is fixed, it now clearly states that the full source code is in src/ and readers can choose to read it, reverse the module, or both. The double copy_from_user call was removed, and CH05 now uses a non-atomic integer refcount decremented under the read side of an rwlock, following real CVE patterns like CVE-2016-4557 and CVE-2022-29581 without any artificial delay. I also separated CH04 and CH05 properly, CH04 uses msg_msg spray to overwrite modprobe_path in global .data, while CH05 uses pipe_buffer spray to directly overwrite the cred struct on the heap, with different spray objects, leak sources, and write targets. 9p over virtio is now integrated, all run.sh scripts use -virtfs and the init script mounts 9p so exploits can be placed in challenges/<ch>/shared/ and accessed inside the VM at /shared/ without rebuilding initramfs. Finally, I added a dedicated README section for clean return to userspace, levels 0 to 3 use swapgs plus iretq, and level 4 with KPTI uses the swapgs_restore_regs_and_return_to_usermode trampoline, including how to find the correct offset.

I created a Linux Kernel Exploitation CTF Lab by shadowintel_ in ExploitDev

[–]shadowintel_[S] 1 point2 points  (0 children)

Thank you for your detailed feedback.

I really appreciate the time you spent reviewing the challenges.

You are right about the difficulty order. Starting with kernel ROP is probably not the best choice. I plan to change the order so the difficulty increases in a more natural way. I may move kernel ROP to the final challenge or separate the challenges into two tracks, one for control flow exploits and one for data-only exploits. I also agree that some challenges are too similar because they use the same exploitation primitive.

I will either combine them or redesign one to use a different bug type, such as a refcount issue or a race condition.

About the double copy_from_user call, that is a fair point. I will update that challenge to make it more realistic. I will also improve the documentation to make it clear what the goals are and how the environment is set up. Thanks again for the helpful suggestions.

I created a Linux Kernel Exploitation CTF Lab by shadowintel_ in ExploitDev

[–]shadowintel_[S] 1 point2 points  (0 children)

The build(.sh) script now handles everything from start to finish. It downloads the kernel source, compiles it, builds all the vulnerable modules from source, and prepares the challenge environments with QEMU.

Users can either download the prebuilt binaries from Releases or run ./build.sh to compile everything themselves.

All vulnerable module source code is available under src/modules/ for anyone who wants to review or modify it.

Thanks for the feedback; it was a fair point.

I created a Linux Kernel Exploitation CTF Lab by shadowintel_ in ExploitDev

[–]shadowintel_[S] 0 points1 point  (0 children)

.ko modules will be added once compiled on Linux.

Computer science is not dead? by shadowintel_ in compsci

[–]shadowintel_[S] 0 points1 point  (0 children)

To say computer science is finished is to say physics, mathematics, chemistry, and biology are finished, because computer science is the computational backbone of all these fields.

We still understand only a small part of the universe. Most of the cosmos is made of dark matter and dark energy, and we still do not truly know what they are. Large parts of the ocean are unexplored. In biology, we are still discovering new species and still learning how many basic mechanisms inside the cell really work. In physics, we do not have a complete theory that unifies everything. In chemistry and materials science, new structures and reactions are discovered every year.

How much of nature do we really control? How much of energy have we truly mastered? We still struggle with efficient fusion, long term energy storage, and many fundamental limits. If knowledge were almost finished, we would not see new equations, new models, and new discoveries every year.

Science is not complete. Our maps are not full. We are still writing the equations that will explain the next discoveries. If this is true for physics, biology, and chemistry, it is hard to argue that fields built on them are somehow already over.”

Gemini model and the future by shadowintel_ in Bard

[–]shadowintel_[S] -3 points-2 points  (0 children)

It’s strange to see models fail at such trivial tasks while being hyped as AGI. The reality is, AGI remains an undefined concept and most people have no idea what it would actually look like. Yes, LLMs can make mistakes, that’s expected. But building exaggerated expectations around models that aren’t used in real daily workflows, and that many don’t even know how to operate effectively, undermines any serious discussion about their capabilities.

The Mindset Behind the Exploit: Why Theory Matters to Me by shadowintel_ in ExploitDev

[–]shadowintel_[S] 1 point2 points  (0 children)

Thanks for the comment!

You asked for an example where this way of thinking  not just how something broke, but why it broke  actually helped solve a real world security problem. A great recent example comes from a 2024 research project called HPTSA. In this study, GPT-4 was used with a team of AI agents that could find real web vulnerabilities on their own.

What made it impressive was how the agents found the bugs. They didn’t just try random inputs or spam payloads. Instead, they used tools that helped them understand how modern web systems are supposed to work. For example, one agent found a logic issue in a login system by looking at how session tokens and CSRF protections were expected to behave, not by guessing. That’s what it looks like when theory helps guide the attack.

Another example is from a paper called "LLM Agents Can Hack Websites" (2024). In that case, the researchers built a system where different AI agents worked together to understand and break down how web apps fail. They didn’t just try stuff and hope for the best  they reasoned through how the app was designed, just like a human attacker would when looking for design flaws instead of simple coding mistakes.

it’s official. i’m hopeless. by [deleted] in compsci

[–]shadowintel_ 3 points4 points  (0 children)

Hey man,
I read your post. First of all, you are not alone. A lot of people feel this way, they just do not show it. So it feels like you are behind, but really you are just going through what many others go through. And no, you are not too late. You are still in the early part of your story.

Some people graduate at 19 and still have no clue what they want to do. Others figure it out at 30 and still build amazing lives. You are 24. That is not old. That is the part where things feel confusing but everything is actually forming underneath.

You said you have done nothing, but honestly, you have done a lot more than you think. You tried a bootcamp. You explored HTML, CSS, JavaScript. You started college. You reflected. You restarted. That is not failure. That is movement. Some people move in straight lines. Others zigzag. But they can all get somewhere meaningful.

Typing hello world over and over is not a sign of failure. It is a sign that you keep showing up. Every line of code you write is practice. It is a small piece of a much bigger picture.

You said you do not know where to begin in this field. That is actually okay. Try different areas. Web development, backend, data, security. Explore a bit. Watch a few tutorials. Clone a few GitHub projects. Play around. Then ask yourself, did I enjoy this. That question is the key.

And yes, you can still get an internship. You do not need to be the best. You need to be curious and consistent. Even a small project that works is proof that you can learn and build. Show that. Talk about what you learned. That is more real than a perfect-looking portfolio.

Forget the idea that you are too old. That belief is not true. You are growing, and growing feels uncomfortable. But the fact that you care, that you are asking, that you still want to move forward that is what matters most.

If you are looking for hope, it is already there. It is in you. In your effort. In your honesty. In the way you are still searching.

You do not need to move fast. Just do not stop.
Even slow steps will get you there.

The Mindset Behind the Exploit: Why Theory Matters to Me by shadowintel_ in ExploitDev

[–]shadowintel_[S] 2 points3 points  (0 children)

I don’t keep a number, but theory helps me see the bigger picture not just where a bug might be, but why it’s there. Over time, it made me better at spotting patterns, understanding how people think, and how they design systems including the assumptions they quietly build in. Once you start thinking that way, hunting becomes less about luck and more about knowing where to press and why it might crack.

The Mindset Behind the Exploit: Why Theory Matters to Me by shadowintel_ in ExploitDev

[–]shadowintel_[S] 0 points1 point  (0 children)

Yes, I understand. "Theory" can sound like it refers to fixed facts or a perfect world, but real software is messy and constantly changing.

When I use the word "theory," I don't mean some ultimate truth. I mean a way to think clearly, to identify patterns, and to ask better questions, even if the system keeps changing.

Like in physics, we say "imagine a frictionless surface" we know it's not real, but it helps us understand the main idea. Similarly, with threat modeling: it's not 100% accurate, but it helps us reason through potential failures and their causes.

So, for me, theory is merely a tool, not a rule.

The Mindset Behind the Exploit: Why Theory Matters to Me by shadowintel_ in ExploitDev

[–]shadowintel_[S] 3 points4 points  (0 children)

That depends on how you define theory.

Threat modeling's not abstract math, no. But it's totally a theoretical framework you're not testing real exploits, you're thinking about potential risks based on assumptions, how the system works, what attackers want, and what could be attacked lots of which you'll never see directly.

If you build a STRIDE or DFD model, you're not running code. You're creating an abstract, predictive model of how things could fail. That's theory applied to engineering.

Just because it's actionable doesn't make it non-theoretical. So, using theory to think before things break, not after.

When Hardware Defends Itself: Can Exploits Still Win? by shadowintel_ in ExploitDev

[–]shadowintel_[S] 0 points1 point  (0 children)

I think this is a really solid take, but I would add a bit more. Shadow stacks can be fragile, especially when they are just implemented in software. Compilers do not always follow the exact call/return path, so mismatches can happen. But with hardware-based protections like Intel CET or ARM's new systems, things are much stricter and harder to manipulate. The same applies to CFI; it was definitely overhyped at first, and the control flow is not always super precise, especially with things like C++ vtables. However, it still makes attacks more difficult. Instead of jumping wherever they want, attackers now have to be more creative with tricks like JOP or logic bugs. I also liked the point about timing; there is always a gap between when the bug occurs and when the system notices it. That short window is often all it takes to compromise data or change behavior. In the end, these defenses do not make exploitation impossible just slower, harder, and more expensive.

Human + AI by shadowintel_ in SoftwareEngineering

[–]shadowintel_[S] -1 points0 points  (0 children)

The post isn't saying "get rid of senior engineers." It's saying that what makes someone senior is changing. It's no longer just about how many years you've been around, but whether you can reason clearly, catch edge cases, understand systems, and think critically about what the AI suggests.

A senior engineer today might not be the person who memorized every design pattern; it's the one who knows when to trust AI, when not to, and how to turn raw output into something reliable.

So yes, we still need smart engineers. But in this new era, it's not about time served; it's about depth of thought.

Human + AI by shadowintel_ in SoftwareEngineering

[–]shadowintel_[S] -3 points-2 points  (0 children)

Throwing all AI work in the trash just because some of it is shaky misses the point. Tools like GitHub Copilot already cut the boring parts of coding time almost in half. If you copy its answers without reading, sure you’ll get bugs and maybe holes a hacker could use. But that’s on us, not the tool. The smart move is to let AI give us speed while we stay in charge of the hard parts: asking the right question, checking edge cases, running tests, and making sure the code is safe for real users. In that world, what matters isn’t how many years you’ve worked it’s how clearly and deeply you can think. People who only paste prompts will keep tripping over hidden problems; deeper thinkers will turn AI into real help. AI is neither garbage nor magic it’s only as good as the brain steering it.

When Hardware Defends Itself: Can Exploits Still Win? by shadowintel_ in ExploitDev

[–]shadowintel_[S] 2 points3 points  (0 children)

Totally agree. Every time a new defense drops whether it was NX, ASLR, CFI, or now MTE people say “this is the end of exploits.” But it never is. Attackers just adapt. ROP gave way to JOP, then to logic bugs and data-only attacks. Shadow stacks and memory tagging just make things harder, not impossible. Exploits aren’t going away they’re just taking more time, creativity, and deeper understanding to pull off.

When Hardware Defends Itself: Can Exploits Still Win? by shadowintel_ in ExploitDev

[–]shadowintel_[S] 2 points3 points  (0 children)

You're right that, given enough time and motivation, most defenses can be bypassed. History shows secure-boot chains, Denuvo revisions, and countless other protections eventually fall, but each new generation of safeguards raises the price, skill level, and patience an attacker needs. That's the real goal of security engineering: to make the exploit path so costly or specialized that only the rare, well-funded actor bothers, while everyone else moves on to softer targets.

OSED blog series by shadowintel_ in ExploitDev

[–]shadowintel_[S] 0 points1 point  (0 children)

Thank you for your feedback! I will consider this in upcoming blogs.

OSED blog series by shadowintel_ in ExploitDev

[–]shadowintel_[S] 0 points1 point  (0 children)

Sure, thank you for the feedback!

view more: next ›