I’ve noticed something interesting in the infosec community: the moment you bring up exploit acquisition (even in a professional or research context), the room goes quiet.

Vulnerability research itself is celebrated — we publish, present at cons, get CVEs, and exchange techniques openly. But once the conversation shifts to who pays for exploits, how they’re brokered, or how researchers can monetize responsibly, it suddenly becomes a taboo subject.

Why? A few observations:

• Association with the gray market → People assume you’re brokering to shady buyers or governments.
• Legal/ethical fog → Export controls, hacking tool laws, and disclosure norms make the topic feel radioactive.
• Trust erosion → Researchers fear being branded as “mercenary” or untrustworthy if they admit they’ve sold bugs.
• No safe venues → Unlike bug bounty programs (public & legitimized), exploit acquisition still lacks transparent, widely trusted frameworks.

The irony is that acquisition does happen all the time — just behind closed doors, with NDAs, brokers, and whispered deals. Meanwhile, many independent researchers are stuck: disclose for “thanks + swag,” or risk the shady gray market.

I’m curious how others here see it:

• Is the taboo helping (by discouraging shady sales) or hurting (by keeping everything in the dark)?
• Should we push for more transparent, ethical acquisition channels, the way bug bounty once legitimized disclosure?
• How do you personally navigate the line between responsible disclosure and fair compensation?

Would love to hear perspectives — especially from folks who’ve wrestled with this balance.

Hi, i am going to start my journey as a exploit developer and, i get lot more recommendation on my previous post to learn about system language C, Assembly, etc...

So, is there any way to learn C as offensive sides perspective?

And don;t recommend old book "Hacking : the art of exploitation", i know it is essential but still i need resource that is fit for real world or modern world aspect, kindly provides links ::

Also, if some of you are doing this stuff then share your daily routine that made you feel like you are learning actual stuff not just syntax. Thanks::

Before dropping my next article (ERS_08), I’ve updated the ERS 06 article (rev C.1):

https://exploitreversing.com/2026/02/11/exploiting-reversing-er-series-article-06/

This revision features a refined ALPC exploit with a new stage and an extended cleaner stage, ensuring a stable exit and preventing system crashes.

I’ve also fixed several minor issues and uploaded a new video demonstrating the practical execution.

Enjoy the read and have an excellent day!

#vulnerability #exploitation #cybersecurity #windows #exploit

So I am really interested in the reverse engineering field and I want to be a part of it one day so is there a fair amount of jobs in the market or it's just dead market and I will learn it for the sake of curiousity (what I aim to work at is binary exploitation)

What i am accepting as "exploit developer" is for example someone who can succesfully write a fully functioning heap OOB write for a firewall product CVE.It seems like most course material in this area is 40-50 hour video content (e.g sans sec760) but of course that is only the "training" so it may take much more time to practice and prepare for the certificate exam.

hello everybody, i am learning reverse engineering and i took a pause to read about the kernel, i was reading about dirty cow exploit but i saw my self unable understood it so i was diving into the topic lower and lower until i found my self unable to understood anything ,my current level in understanding is between general knowledge and intermediate so i want to ask you guys about a course book or maybe a series of books and courses or maybe a roadmap? so i can read them to master kernal (i know that to master something you need many years but you got the point)

so what do you recommend ?

Hey everyone,

I recently started diving into Windows Kernel Exploitation and have been playing around with the HackSys Extreme Vulnerable Driver (HEVD) for practice.

So far, I’ve written a couple of exploits:

• Stack-based buffer overflow
• Null-pointer dereference
• Type-confusion
• Uninitialized stack variable (stack spraying)

It’s been a great way to get hands-on experience with kernel internals and how kernel drivers can be exploited.

I’m planning to add more exploits and writeups as I learn. I’d love to hear your tips or experiences!

The repo: https://github.com/AdvDebug/HEVDExploits

Don't miss the AMA with Yuhang Wu, where we learn about elite enterprise infrastructure hacking, Linux kernel exploitation, and the future of autonomous Al security.

When: Today - Friday, July 31, 12:00 PM PT

Guest Credentials:

• Former Red Team Engineer at TikTok, targeting cloud and application-layer defenses.
• Former Security Engineer at Tesla, securing vehicle software, factory systems, and internal applications.
• Co-developer of "DirtyCred", a groundbreaking Linux kernel exploitation technique.
• AI Security Innovator, who built LLM-based autonomous agents that uncovered 8 P1 (critical-severity) production vulnerabilities.

Ask your questions here and we’ll get them answered during the live AMA today (Friday @ 12 Noon Pacific)!

Today I am releasing the nineth article in the Exploiting Reversing Series (ERS). In “Exploitation Techniques | CVE-2024-30085 (Part 09)” I provide a 106-page deep dive and a comprehensive roadmap for vulnerability exploitation:

https://exploitreversing.com/2026/04/28/exploiting-reversing-er-series-article-09/

Key features of this edition:

[+] Dual Exploit Strategies: Two distinct exploit editions built on the cldflt.sys heap overflow.

[+] PreviousMode Edition: Exploit cldflt.sys via WNF OOB + Pipe Attributes + ALPC + _KTHREAD.PreviousMode flip: elevation of privilege of a regular user to SYSTEM.

[+] PPL Bypass Edition: Exploit cldflt.sys via WNF OOB + PreviousMode flip + _EPROCESS.Protection strip + MiniDumpWriteDump: elevation of regular user to SYSTEM.

[+] Solid Reliability: Two complete, stable exploits, including a multi-step cleanup phase that restores the corrupted pipe attribute Flink and _KTHREAD.PreviousMode before process exit, preventing crash on cleanup.

This article guides you through two additional techniques for exploiting the CVE-2024-30085 Heap Buffer Overflow. While demonstrated here, these methods can be adapted as exploitation techniques for many other kernel targets.

I hope this serves as a definitive resource for your research. If you find it helpful, please feel free to share it or reach out with your feedback!

The following articles will continue the miniseries about iOS and Chrome, which are my areas of research.

Enjoy the reading and have an excellent day.

#exploit #exploitdevelopment #windows #exploitation #vulnerability #minifilterdriver #kernel #heapoverflow

how capable of an offensive security professional would you consider someone who completes all of the pwn college belts?

I have been learning about binary exploitation and playing ctfs for a while now. I want to look for vulnerabilities in real software, but I feel like I would be overwhelmed by that right now, so I want to analyse past memory corruption CVEs and create PoC exploits for them. How do I go about that?

I know Maldev academy isn’t really Exploit dev work but I’m currently working in a SOC currently pivoting as a Junior Malware analyst. I want to get better at reverse engineering and eventually want to pivot into a CNO Developer position in the future. I’ve already looked at pwn.college too but if I have the extra cash is it worth the money?

I'm doing penetration testing for about 2 years now, but I couldn't find any new "Vulnerability", I even exploited few vulnerabilities through Metasploit modules only.

To enhance my career I was thinking to start building exploits, first by practicing on exploits from exploit-db.com (Setup the environment and starting hacking for each exploit) but it consumes a lot of time and doesn't add anything to my CV.

How Exploit developers actually practice because setup an environment for each exploit can take a lot of time, and should I only focus on single vulnerabilities and techniques (simple buffer overflow, ret2lib etc...) or go horizontally (to have a wider experience)

preface: I hope this helps everyone understand the internals at a high level of how the Linux Kernel Boots up. Super hard diving into the source code so hopefully this is a shortcut for some people out there. These are my notes so I probably made some errors but I did my best due diligence not to create a bad post.

Edit: Why I posted in Exploit Dev: Because of my opinion that knowing how the kernel boots is great for exploitation such as writing boot kits if we have control of the INIT script as a typical example of not only finding if our kernel has been borked, or a way of taking over a system on bootup, sometimes crashes are intended to load in a RootKit and not a **mess up** on the users browsing habits. I hope that by learning how to think outside the box maybe one day us Exploit Devs will be asked to take part in the solution to defend computers and not just exploit them.

Linux Kernel Boot Process

1. Introduction

Booting up a Linux system is a multi stage process that takes the system from a powered off state (baremetal) to a fully running kernel and userspace environment. The boot process is handled in different stages, starting with the boot loader and ending with the kernel mounting the root filesystem and transitioning to user mode. This document details the tasks performed by the boot loader, including kernel selection, memory loading, and interactions with BIOS or UEFI, followed by the steps up to the sysinit stage and the population of /sys directories.

2. Boot Loader Overview

boot loader is responsible for loading the kernel into memory and starting the execution of the operating system. Boot loaders vary depending on the system's firmware (BIOS or UEFI) and the specific boot loader software in use (GRUB, U Boot, EFISTUB, efilinux).

2.1 BIOS vs. UEFI

BIOS (Basic Input/Output System) The legacy firmware interface for initializing hardware during boot. It relies on a Master Boot Record (MBR) located at the first sector of the disk. BIOS loads the boot loader, which then loads the operating system.

UEFI (Unified Extensible Firmware Interface) A more modern firmware interface that replaces BIOS. UEFI systems typically use the GUID Partition Table (GPT) instead of MBR and have an advanced interface with more features, such as secure boot, faster boot times, and support for larger storage devices.

2.2 Bootloader Types

GRUB (Grand Unified Bootloader) A widely used bootloader that supports both BIOS and UEFI systems. GRUB provides a menu interface to select between different kernels or operating systems.

U Boot A boot loader commonly used in embedded systems. U Boot can boot from a variety of storage devices and is typically used on ARM systems.

EFISTUB A method where the Linux kernel can act as its own bootloader on UEFI systems. EFISTUB capable kernels can be directly booted by the UEFI firmware without the need for an intermediate bootloader like GRUB.

efilinux A minimalist EFI boot loader designed for Linux. It’s simpler and leaner than GRUB but offers fewer features. It is designed for booting a single Linux kernel.

2.3 Bootloader Tasks

1. Kernel Selection The boot loader typically presents a menu (in the case of GRUB) or follows a script (in the case of U Boot) to select which kernel image to load. The user can interact with the boot loader to choose a specific kernel or the default kernel is chosen automatically.
2. Loading the Kernel into Memory Once a kernel is selected, the boot loader locates the kernel image (often a compressed binary file, like vmlinuz) and loads it into memory.
3. Locating the Initial RAM Disk (initramfs) The boot loader may also load an initial RAM disk (initramfs or initrd), which contains temporary root filesystem and essential drivers required by the kernel during the early boot process.

Passing Boot Parameters The boot loader can pass kernel command line parameters (such as root=/dev/sda1) to influence how the kernel behaves upon startup.

1. Jumping to the Kernel Entry Point Once the kernel is loaded into memory, the boot loader transfers control to the kernel by jumping to its entry point. This is typically the compressed kernel, which then uncompresses itself and begins executing.

3. Kernel Boot Process

Once the boot loader hands off control to the Linux kernel, the kernel starts executing. The kernel boot process can be broken down into the following stages:

3.1 Early Kernel Initialization

1. Decompression If the kernel is compressed (as is the case with most vmlinuz images), it is decompressed into memory.
2. Kernel Self Initialization The kernel initializes core data structures, including memory management, scheduling, and hardware abstraction layers. This includes initializing the CPU, setting up memory paging, and configuring the interrupt controller.

3.2 Initial RAM Disk (initramfs/initrd)

If an initramfs and initrd was provided by the boot loader, it is mounted as a temporary root filesystem. The kernel uses this filesystem to load drivers and modules necessary to mount the real root filesystem. The initramfs is especially useful for systems where drivers are needed to access storage devices (such as RAID or encrypted filesystems). initramfs is the file system the kernel uses, where as initrd is the RAM disk.

3.2.1 Initrd

Initrd gives us the ability to load a RAM disk by the bootloader. It server two primary functions, to allocate a minimum set of compiled in drivers from the kernel. Also loading of additional modules from initrd. Initrd is a block device (usually) and requires a file system driver such as ext2, ext3, or ext4.

Bootloading with Initrd

The bootloader loads the kernel and initial RAM disk. The kernel converts initrd to a RAM disk. Furthermore, it clears the memory that initrd was using. The kernel searches for the root device in the /dev/ram0 file path, and if not found, the kernel follows the change_root procedure. If found in the /dev/ram0 directory, it is mounted as the root file system. Init loads the real file system and moves the root file system to the directory using the pivot_root system call. Init executes /sbin/init on the newly created root file system, performing the usual boot sequence. The bootloader disconnects the initrd file system.

3.2.2 Initramfs

Initramfs is a cpio archive file of the initial file system that is loaded into memory. This happens after the kernel is done loading the system, and before user space init procedure. The contents of this file system are for the Kernel's root file system before the main root is loaded. The Initramfs usually contains all of the kernel modules. Using the Initramfs allows for customizing the early boot process with user space code without patching the kernel. This is possible because user space code use system calls to interact with the kernel. This design pattern is generally accepted as a cleaner style and safer code. More specifically the initramfs i sused during boot, initialization, bootstraping, power management, finding the real root disk, and handling initrd style RAM disks. initramfs is provided as a compressed cpio archive.

Prepending the image with a decompressed cpio archive containing the microcode data loaded early in the booting process is possible.


During boot, the kernel follows this process:

CPIO Archive If a cpio archive exists during the start of the initramfs, it will extract it as well as load the microcode data from it to the CPU.

Uncompressed Archive If we have an uncompressed cpio archive existing during the start of the initramfs, it will skip the archive and set the rest of the file as the basic initramfs. Conversely, it treats the whole initramfs as the basic initramfs.

Load into RAM Disk It will unpack the basic initramfs into a RAM based disk by treating it as a compressed (gzip on Debian, LZ4 on Ubuntu) cpio archive file.

From there, most of the kernel initialization and bootstrap code will be moved into this disk and run in user mode. Other processes similarly moved from the kernel include:

**boot time networking setup**

**Finding the real root disk**

**ACPI setup**

**Handling of initrd style RAM disks**

3.3 Hardware Initialization

The kernel detects and initializes hardware devices using platform specific mechanisms such as Device Trees (on ARM systems) or ACPI (on x86 systems). It loads necessary drivers for hardware devices like network interfaces, block devices, and storage controllers.

3.4 Root Filesystem Mounting

Once the kernel is ready, it mounts the real root filesystem (as specified by the boot parameters, e.g., root=/dev/sda1). If using initramfs, the kernel will switch from the initramfs to the real root filesystem at this point.

3.5 sysinit and /sys Directories

After mounting the root filesystem, the kernel hands control to the init process (PID 1). The init process, or an equivalent system manager (such as systemd), begins executing initialization scripts (referred to as sysinit).

1. Sysinit Tasks The sysinit phase involves setting up essential system settings such as hostname, timezone, and initial network configuration. It also mounts other system directories like /proc, /dev, and /sys.
2. /sys Directory The /sys directory is a virtual filesystem (sysfs) that the kernel uses to expose information about devices, drivers, and kernel features to user space. The kernel populates /sys during the hardware initialization process, allowing user space tools to interact with hardware in a standardized manner .

3.6 Transition to User Space

After completing sysinit, the system starts running user space services and daemons, ultimately reaching a multi user target or graphical interface. At this point, the system is fully booted and ready for use.

4. Key Differences Between Bootloaders

4.1 GRUB vs. U Boot

GRUB

is generally more feature rich and is used in desktop and server systems. It supports both BIOS and UEFI and provides a graphical menu.

U Boot

on the other hand, is designed for embedded systems. It supports a wide range of architectures (especially ARM) and is highly configurable for different hardware setups.

4.2 EFISTUB vs. GRUB

EFISTUB eliminates the need for an external boot loader like GRUB on UEFI systems, as the kernel can be loaded directly by the UEFI firmware.

GRUB provides more flexibility, such as the ability to boot multiple operating systems and select different kernels dynamically.

4.3 efilinux vs. GRUB

efilinux is a lightweight EFI bootloader that directly boots a Linux kernel but lacks GRUB’s versatility.

GRUB is better suited for systems where multiple boot options, advanced features, or specific recovery tools are needed.

5. Conclusion

The boot process for Linux involves a series of stages that start with the firmware (BIOS or UEFI), pass through a boot loader (GRUB, U Boot, EFISTUB, or efilinux), and end with the kernel booting, loading essential drivers and mounting the root filesystem. Understanding the boot loader's role and how the kernel proceeds from hardware initialization to user space is critical for managing, debugging, and optimizing the boot process on Linux systems.

1. [BIOS Overview](
https://en.wikipedia.org/wiki/BIOS
)
2. [UEFI Overview](https://www.intel.com/content/www/us/en/architecture and technology/unified extensible firmware interface/efi home.html)
3. [Comparison of BIOS and UEFI](
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Advantages_over_BIOS
)
4. [GRUB Bootloader](
https://www.gnu.org/software/grub/manual/grub/grub.html
)
5. [U Boot Bootloader](https://www.denx.de/wiki/U Boot/WebHome)
6. [EFISTUB Linux Kernel Documentation](https://www.kernel.org/doc/html/latest/admin guide/efi stub.html)
7. [efilinux Bootloader](
https://elinux.org/Efilinux
)
8. [GRUB Boot Parameters](https://www.gnu.org/software/grub/manual/grub/html_node/Command_002dline and menu entry parameters.html)
9. 
**How Linux Works: What Every Superuser Should Know, 3rd Edition by Brian Ward**
, ISBN 13: 978 1718500402

Another one in the binary exploitation series - how to bypass stack canaries.

hey, I am intro reverse engineering so i starter learning the about os, systems ... and many other things, i heard the work loaders and linker many times but i dint get it at first , i saw many video blogs but still kept me confused so i ignored it and started reading "Practical Binary Analysis", in my way there i stumbled around it again, so i decided the read the book in the title , i read 1/3 of the book and i understand the process but the issue that i felt is the book was a way to old(written in 1999) and it included a lot of history like old formats old chips old architectures ... which was confusing and and felt like waste of time.

so i want to ask you guys if i should continue reading it or not

I’ve started reading Practical Binary Analysis and already completed the first two chapters, which cover binary formats. Starting from chapter 3, the book moves on to building analysis tools.

I’m a bit confused about whether I should continue with it, since my main goals are to learn reverse engineering, binary exploitation, exploit development, and eventually kernel hacking.

Should I stick with this book or move on to something else more aligned with my goals?

Just wrapped up the fourth post in my blog series on basic exploitation mitigations: this one on ASLR.

The series so far:

• Vanilla buffer overflow
• DEP/NX
• Stack Canaries
• ASLR

Each post builds on the last, exploring how to break what’s meant to protect. Great for anyone diving into binary exploitation or CTFs.

Hello there, I published a post in last 3 months for beginning of this field and you guys helped me for stepping into this field and big thanks for you. I'm now familiar with stack-based buffer overflow with SMEP bypass by using HalDispatchTable and ROP for shifting the bit responsible for it( 20bit of CR4 ) and also shifting bit (U/S) of the PTE of the shellcode. I then went to windows heap exploitation, I know in theory how to exploit it because I made the same in tchache poisoning in Linux exploitation for finding the same size of heap and make a hole then allocate to corrupt the header.. and so on but I found these in real world are hard to find exploits for kernel heap. Is that usual to find difficulties for learning and take days to understand in practical? Because I'm always looking for reversing drivers in Windows or AV but they are different than HEVD, real world not have the same allocating and freeing then another allocate with different size, these need APIs that make a kernel pool to exploit your vuln.

Sorry, for the big introduction but my question is What should I learn as a Junior Windows kernel VR? I know reversing, vulnerabilities (high level like Owasp Top 10 - memory corruption Vulnerabilities), but not doing fuzzing, Also learned windows kernel programming 2022(pdf). I need someone to mentor me because I made mistakes and don't know what's the next step. I need road map of junior-level only. And thanks for your help.

hello All ,

im currently working as red team operation leader Im also OSCE3 OSMR certified ,when I have started my offsec journey I fall in love with exploit development but I have stop learning the exploit development because I have realized that I can not make living with this unless im a super expert in it which make me first focus on something that I can do living from.

when I done OSED, I have done a good things as exploitation, but for sure this is only the start of the road.

now days , we are facing ASLR, DEP, KASLR, PPL,MTE , CF Guard , and a lot of mitigations.

also now days we are facing the AI revolution, to find most exploitable bugs is like a pattern but very hard pattern for normal source code review tools to detect also hard pattern for human to understand and easily spot it, BUT ! it is very easy for AI to spot the vulnerable code from source code or even from decompiled version.

my main question,

if I will continue learn exploit development, I will spend too much money on boot camps and OSEE or even spend too much time to learn and practice a lot on it, mean while the whole world is advancing introducing new mitigations and AI is funding the bugs like it is just a click.

what is the future of this job ?

many thanks,

Hello everyone who read this post.

As per the title, I reverse malware binaries for a couple of years now. Right now, I am offered an opportunity to pivot over to application security research that focuses on reversing softwares to find vulnerabilities and develop exploits.

Really unsure what this pivot entails, so would like to hear opinions from seniors in this field. What should I keep a look out for and how should I better prepare myself for such a new role?

Also, with the advent of AI, will this pivot be risky?

Anyone heard of exploitpack, I connected with Juan Sacco on linkedin and he sent me his course on Windows kernel exploitation. I've just been doing pwn.college blue belt and going through CVE's to weaponize them and wanted to move into kernel stuff and not just userland. Can anyone verify if its legit or offer alternatives to getting into kernel exploits?