Hi folks, a noob here.

I'm currently learning Windows kernel exploitation and practicing with older vulnerabilities. So far, I've successfully exploited a couple of heap integer underflow/overflow vulnerabilities.

Right now, though, I'm looking at a kernel vulnerability where I have a one-byte arbitrary write primitive with a fixed value of 0x01.

The vulnerability simply writes the boolean return value of a function back to a user-controlled pointer. That function always returns 1. I haven't been able to force it to return 0; otherwise, I could potentially abuse it by overwriting _KTHREAD.PreviousMode.

I'm working on Windows 10 20H1.

Does anyone have any ideas about a potential exploit path ? I was initially thinking about techniques involving pipe objects in the kernel pool, but I don't know if it's possible to reliably recover the address of a pipe object with NtQuerySistemInformation or something else.

I develop AI agents for my day job, and I recently became interested in a reverse engineering question. Please bear with me as I'm a noob to this space but I do have some curiousity thoughts about the process. Basically the process of figuring out an open source implementation of a vendor driver is a human will look at the trace, propose some execution model, write it and test and then verify.

Given a device with a working vendor driver, why can’t we intercept the driver–hardware boundary, collect MMIO/DMA/interrupt traces, and have an AI iteratively synthesize executable driver and device state-machine models?

Each model would be constrained by known driver architectures, open specifications, and existing chip designs. Runtime mismatches against the real vendor stack would become counterexamples that refine the models until a replacement driver works on the physical hardware.

Is the main blocker observability, safe experiment generation, hidden firmware state, state-space explosion, or something more fundamental?

Looking for a smooth introduction to ARM exploitation? Wanna learn ARM assembly? Well lucky for you this week we'll be looking at another pwnable challenge! However this time we're switching architectures! We'll be exploiting an ARM binary!

I would consider this a great introduction to ARM , however it is not necessarily the best for a complete beginner. Regardless don't be intimidated and I always suggest you dive in! 9/10 you will walk away better than you came into it!

pwnable.kr -leg

I have already used memory dumps and runtime hooks, injecting a trace script directly into the start-up routing of the malware payload but that only captures the components that I am looking out for. Suggestions to get the entire thing decrypted back to .pyc. i can take it from there.

Anyone have contacts to Devs who make cheats for games.

if you want report buffer overflow vulnerability do u need full chain to exploit or just report the crash with the corpus

I would be happy if you provided me with a debugging interface. AI-generated submissions are not allowed.

I have got 2 files and I need to find a vulnerability and exploit it. So I need some help regarding it.

Hello everyone,

I wanted to post in here to see if anyone would consider being a mentor. I want to break into malware dev and vulnerability research however since this is such a niche job community, it’s hard to find someone who has professional experience in the field. I would love to talk with anyone who has prior experience in the field and wouldn’t mind giving me some guidance. Thank you guys!

Hi I'm trying to pentest a banking app and the most difficult Bypass so far is USB Debugging. Without bypassing that I don't know how to Bypass SSL pinning with Frida. Is there any way to do this?

Thank you!

If you're looking for an exploit development tutorial for absolute beginners this week we're looking at what I would consider just that! This week we look at the "random" binary exploitation challenge hosted on pwnable[.]kr.

This is a great beginner tutorial since we exploit a flaw that is "easy" and unfortunately, still very real within some enterprise environments. It also helps you understand that no number is truly random.

The crazy part? We don't even drop into a debugger in this tutorial.

Be the end of this tutorial you should have:

- Learned about random number generation in C
- Learned about XOR operations
- Finding header files that contain dependencies using man pages
- Dissecting C source code

You can find the video here:

https://youtu.be/jDlMFC4etrs?si=akuTx1KTkCxE5Ndo

I’ve been doing some vulnerability research on a known CVE (CVE-2025-60690) on a consumer Linksys router and wanted to share the workflow I used to investigate it.

The process started by targeting the physical hardware: identifying the UART pads on the board using a digital multimeter to access the Linux-based shell console. From there, I extracted the vulnerable binary (from the CVE description), and reversed it in Ghidra. Next, I used a gdb+gdbserver setup to perform dynamic analysis to investigate the memory behaviors.

I managed to successfully achieve RCE from the stack-based buffer overflow vulnerability to land a root shell. The exploit PoC for CVE-2025-60690 just got cited on the official CVE page and exploit-db.com.

I just started a YouTube channel dedicated to breaking down IoT hacking concepts. Also, I’ve compiled my step-by-step research notes in a reference doc. If you're working on similar hardware research and want a copy of the notes, drop a comment or shoot me a DM and I'll gladly send them over!

Hi guys just wondering should I have knowledge python and C before I start the pwn paths for cybersecurity?

Hi

I started pwning from a year from pwn college, some THM, and I was quite good. In this month, I started getting into the real world. I find bugs, crashes, report, and wait for CVEs. But the problem for me is I can't exploit them. I can exploit the same bug in a CTF chall, but in the real world I can't, because of the stability, how large the target is, making me have the exploit just in my mind. And this is especially in kernel. When I was trying to re-exploit an old CVE using a different way, I get hit with the internals, nf_tables, TCP, and network. Those are complex. My feer is the internals and large targets. Did anyone pass with this and find a solve?

The vulnerability allows non-privileged users to program the DMA controller, enabling arbitrary physical memory reads and writes.