Everything About Wipeload

Hi everyone! It’s OUYA77, the PM of the Wipeload team.

First of all, I’d like to give 500 rounds of applause to every member of the team. 👏👏👏👏👏 Everyone gave it their all in their own role, and thanks to that, we were able to make it through this long journey and achieve results that we’re genuinely proud of.

Previous articles

https://hackyboiz.github.io/2026/06/06/OUYA77/Wipeload_step1/en/

https://hackyboiz.github.io/2026/06/21/ji9umi/Wipeload_step2/en/

https://hackyboiz.github.io/2026/06/26/ji9umi/Wipeload_step3/en/

https://hackyboiz.github.io/2026/07/13/OUYA77/Wipeload_step4/en/

https://hackyboiz.github.io/2026/07/19/gongjae/Wipeload_step5/EN/

https://hackyboiz.github.io/2026/08/01/gongjae/Wipeload_step6/EN/

https://hackyboiz.github.io/2026/08/08/banda/Wipeload_step7/EN/

https://hackyboiz.github.io/2026/08/15/banda/Wipeload_step8/EN/

And of course, a series this long would mean nothing without the readers who stayed with us all the way to the end. Thank you so much for walking this path with us. 😆

Think of this post as the end credits of a movie. We’re going to look back on the path we’ve taken, revisit the moments that made Wipeload what it was, and share a little bit of everything behind the project.

You know the rule, right?

The real ones stay until the credits are over. 😉

Gi-Seung-Jeon-Gyeol (起承轉結) is a traditional four-part narrative structure commonly used in Korea and other East Asian cultures. Gi (起) introduces the story, Seung (承) develops it, Jeon (轉) brings a shift or turning point, and Gyeol (結) concludes the narrative.

For this final Wipeload article, we decided to follow that same structure: beginning with why the project started, moving through how we studied and built our exploits, looking back on the point where individual work turned into a full exploit chain, and finally reflecting on what lies beyond Wipeload.

Gi (起) — Where It All Began

We already talked about how the project started back in Part 1, so rather than repeating the whole story here, I’ll just bring it back up briefly.

→ https://hackyboiz.github.io/2026/06/06/OUYA77/Wipeload_step1/en/

To be honest, at first I wasn’t even sure whether this would really work.

Still, I thought, “If each of us can develop at least one 1-day PoC, maybe we can make this happen.” So we decided to just go for it.

And when I was writing Wipeload Step 1, only one exploit chain had actually been completed, while another was still in development. Even then, though, I trusted our team. haha😋

Now that all of the chains have been successfully completed, I’m really happy that I can write this final post with a smile. ^-^☆

Since we already covered the motivation behind the project above, let’s talk a little about what the early days of Wipeload were actually like.

True to the name Wipeload, before we could start walking the path, we first had to work on ourselves a little(?).

OUYA77:

What’s everyone up to today?
Anyone wanna study together? 👀

Chunsik:

I studied this morning and I’m out right now..ㅠㅠ
I’ll hop on later tonight if I can!

OUYA77:

Lmaoooo yeah, hop on if you can and let me know.
I might be completely passed out by then though 🫠

Look at you being productive.

Apeach:

I’ll join after dinner too.

OUYA77:

Alright, let’s gooo.

Ryan:

I’m just gonna wrap a few things up and I’ll join soon.

OUYA77:

Lmao, guess I’m not getting any rest then.
Let’s gooo 🔥

At the beginning, we aligned on the overall direction of the project and decided what each person would study. Since most of us did not have much prior experience in these areas, we were essentially starting from zero. That meant a lot of studying, a lot of reading, and a lot of trial and error.

Studying alone can get exhausting pretty quickly, but as you can see from the KakaoTalk screenshot above, we basically locked ourselves inside an endless Discord prison(?) and studied together.

Thanks to that, the path(道) never really felt lonely. haha😃

Once everyone had built up a certain level of understanding, we also met offline to share what we had learned and discuss what we should work on next. We spent the entire day together. We had lunch, spent the afternoon preparing what we wanted to present later that evening, and then wrapped up the day by sharing everything we had studied so far. (And yes, after lunch, ogu bought us coffee while we were studying. That is definitely not a secret.)

Thanks for the coffee, ogu!

By the evening, everyone had shared the 1-day exploit they planned to develop as part of the chain. And with that, the actual exploit development finally began.

That was the beginning of our story.

Now, shall we hear how the other team members remember it?

• ji9umi

  I ended up joining the Wipeload Project a little late because I spent quite a bit of time debating whether I should take part 🙃 Even though I knew the project itself could turn into a really interesting journey, I still had some trauma from getting burned pretty badly by V8 in the past, so it wasn’t an easy decision to make.

  But I figured that if I ran away from it again this time, I might never get over it—so I decided to work up the courage and give it another shot! If I’d had to choose the target myself, I probably would’ve stumbled right out of the gate, but fortunately, the 1-day vulnerability I needed to analyze had already been picked, which took some of the pressure off.

  At first, I thought things might be relatively straightforward since both a PoC for CVE-2023-3079 and another PoC for bypassing the V8 Heap Sandbox were already publicly available. I figured I could study those materials, understand them properly, and turn what I learned into a write-up.

  …But of course, reality wasn’t quite that easy, haha.

• gongjae

  I was unexpectedly “kidnapped” by OUYA77 😂, so I’ve been on this ride with banda right from the start. Since I was strictly a Windows guy, I worried a lot about what I could actually bring to the table in a project tied to Chrome. But in the end, I’m really grateful OUYA77 roped me in haha.

  My part was CVE-2023-21674, a vulnerability used for the Sandbox Escape (referencing Theori). Since I was initially studying it as a 1-day rather than focusing on the exploit chain, it went smoother than expected and I grasped it fairly easily… or so I thought.

  That was just me being a naïve mortal before facing the Chrome chaining nightmare that awaited me. Ignorance was bliss, so I guess I was genuinely having fun back then… haha.

• banda

  I was also fortunate enough to join the Wipeload team, thanks to OUYA77, who had already picked me out as someone they wanted on the team even before the project officially began(?) 😄

  When the project started, I was particularly interested in some of the more specialized areas of the Windows kernel, such as the Filter Manager, MDLs, and Kernel Streaming. Through the chaining process, I wanted to gain a much more solid understanding of these kernel attack surfaces and exploit primitives. At the same time, after spending most of my time working almost exclusively on Windows-related projects, I also saw this as a great opportunity to explore and study attack surfaces such as the Chrome Renderer and Sandbox.

  The part I was responsible for was CVE-2023-29360, the vulnerability used by Theori for the privilege escalation to SYSTEM after escaping the Chrome Sandbox. Since kernel vulnerabilities were already somewhat familiar territory for me, I spent quite a bit of time thinking about what else I could take away from working on a 1-day. In the end, I decided to give myself a bit of a theme and focus on learning more about specialized attack surfaces such as MDLs, as well as exploit primitives that I still felt I was lacking in.

  At the same time, I tried to follow along with the chaining process where each of the other team members played their part, constantly looking up anything I was curious about and doing my best to understand how everything fit together haha.

Seung (承) — Sharpening Our Skills: The 1-Day Exploit Begins

Chain 1

• OUYA77

After about two months of studying and preparation, we finally moved on to exploit development. When I was studying Chrome last year, debugging was honestly one of the most painful parts. These days, though, AI tools have gotten so much better that compared to last year, I was able to get much more useful guidance along the way. Because of that, developing the first chain went more smoothly than I expected.

Last year, I had already managed to get V8 RCE working on Linux, but I was stuck trying to port it to Windows. This time, with a little help from our good friend Claude, I finally figured out the right WASM page offset and got the V8 RCE working on Windows Chrome as well..!!

But honestly, what came next was the real problem…

(To be continued in Jeon (轉)…)

Chain 2

• ji9umi

  The second exploit chain covered in the Wipeload Project was based on Theori’s 2024 “Chaining N-days to Compromise All” series. My part focused on Part 1: V8 RCE and V8 Heap Sandbox Bypass, which served as the starting point of the chain.

  Since PoCs for both parts were already publicly available, things went pretty smoothly up to the point where I tested them in a standalone V8 environment. However, V8 is ultimately just one of the many components that make up Chrome, so the next step was adapting the V8 PoCs so they could actually be used against Chrome 🔄

  The publicly available PoCs were tested against a specific commit hash, and I was able to confirm that they worked without much trouble once I reproduced the same environment. The tricky part, though, was finding a stable Chrome environment to work with. Chrome and V8 versions don’t map neatly one-to-one, and vulnerability fixes are often shipped by upgrading the bundled V8 version independently of Chrome’s versioning. That made identifying a suitable build one of the more important parts of the process.

  Fortunately, this vulnerability fell within the range of versions available through Chrome for Testing, which provides prebuilt Chrome binaries, so setting up the environment was relatively painless. If I’d had to build everything from source just to test it… even thinking about it sounds painful 😵

• gongjae

  For Part 2, I kicked off my studies by reading Theori’s blog post and checking out a GitHub repo with a BSOD PoC to trigger the ALPC kernel UAF for the Sandbox Escape. Since I was approaching it as a standalone 1-day before doing any chaining, directly triggering the ALPC within Windows to cause the UAF and hit a BSOD was something I could pull off pretty quickly.

  I analyzed the differences between Theori’s methodology and the BSOD PoC code, and managed to successfully trigger a BSOD by writing the code my own way. But after that… I really had to scratch my head over how to handle the Thread Spray, including reclaiming the freed thread.

  I figured out a way to do it in a standard Windows environment, but knowing that for the Part 1 chain, all of this had to be executed within Low IL… I really spent a lot of time agonizing over how to make that work.. haha.

• banda

  For my part, I analyzed the mskssrv.sys-based Kernel EoP covered in Theori Part 3, and alongside Chain 2, I also ended up studying from the kernel side how an attack starting from the Renderer could eventually reach SYSTEM privileges. Reproducing the vulnerability required opening multiple handles, matching the state and role of each one, preparing the communication structure and streams in the correct order, registering the Consumer, and then strictly following the call sequence all the way through PublishTx and ConsumeTx. I think this was the part that took me the most time.

  After that, the chain uses the ALPC cross-process Write primitive to manipulate the execution flow of a Medium process, and by invoking mskssrv.sys from that same process, it becomes possible to reach a SYSTEM process. While looking at this part of the chain, I actually got the impression that unless the kernel vulnerability depends on something like repeatedly starting a service to trigger it, or on a race condition with very specific execution requirements, many other kernel driver vulnerabilities could probably be chained in a similar way as long as you can successfully place the exploit into the right process context.

  More than my own part, though, watching the other team members reproduce the PoCs on the exact same V8 commit and then port them to an actual Chrome environment, or take the ALPC UAF from Low IL all the way to a working Thread Spray, really made me realize just how different the difficulty of building an exploit chain is compared to analyzing a single vulnerability on its own… haha.

Jeon (轉) — Connecting the Pieces: Chaining Begins

Chain 1

• OUYA77

The Chrome sandbox escape vulnerability had originally been implemented on Linux, so the first challenge was porting it to Windows. Fortunately, as I mentioned back in Wipeload Step 1, the Black Hat materials documented the exploit flow and primitives in quite a bit of detail. It still took some effort, but I was eventually able to reproduce the exploit on Windows without too much trouble.

While writing this exploit, I encountered the AAF primitive for the first time. Up until then, I was much more familiar with the classic AAR/W primitives, so discovering AAF honestly felt like a lightbulb moment.

Once you understand that you already have AAF, the rest suddenly starts to look very different. I spent some time wondering what else I still needed to do, and then realized, “Wait… I’m basically already there.” From there, I was able to place the data I wanted into the dangling pointer and successfully complete the exploit.

The real final step was chaining the Renderer RCE with the sandbox escape.

The Renderer RCE I had at the time simply executed a calculator shellcode, and if I remember correctly, the usable space for that shellcode was only around 4 KB. The full sandbox escape exploit, however, was roughly 2.7 MB, so I needed somewhere much larger to place it.

But!! There was one reliable memory region I had kept seeing while working on V8 by myself last year. The address was clean and predictable, so I used VirtualAlloc from the 4 KB shellcode to allocate that region with RWX permissions, then copied the sandbox escape shellcode there.

And then, finally…!!!

—>

I popped calc ㅎ.ㅎ

Once everyone’s exploits had been polished up to a reasonable point, we got together to start preparing the write-ups.

At that point, one chain was already complete. For Chain 2, each individual vulnerability had been successfully exploited, but they had not yet been chained together.

Since publishing the posts themselves would take some time, we first laid out the release schedule, worked on thumbnails, and had a very productive(?) time together.

Over lunch, we also got to hear about OUYA’s primitive(?) building adventures,

and then moved to a cafe where we held another very serious meeting.

After that, we played a board game called Catan.

In Catan, you build settlements around resource regions and connect them with roads.

And of course, in true Wipeload fashion, even during a board game…

we were still building roads.

So who do you think won the ultimate road-building game?!?!?!?

It was!!!

Yep. Me (OUYA77).

As the PM of a project literally about “walking the path,” I obviously couldn’t afford to lose at a road-building game.

So I spent most of the game causing chaos and talking nonstop, then the moment I saw a path to victory, I suddenly went completely silent, hoarded my cards, and dumped everything at once without even breathing.

And somehow, I won.

Much love to my kind teammates who definitely let me win on purpose(?).

After wrapping up the meeting in high spirits, we finally started writing the series.

Posting the first article from a brand-new account with literally 0 followers felt pretty strange.

Still, I think we published it with the mindset of:

“Let’s use this project as a fresh start and get active again.”

Then, starting from Wipeload Step 2, one of the posts suddenly reached 8.3K views, which was honestly pretty surprising. haha

And from there, we kept climbing one step at a time.

Whenever it was someone else’s turn to take the next step,

Apeach:

F…i…n…a…l…l…y…

While kernel debugging, I got the ROP chain working to pop calc even as the values changed along the way. Now I’m going to work on making the whole thing run automatically with a single click.

OUYA77:

Ooooh, AWEEEESOME~~~
Absolute legend.

every member of the team stepped up and climbed it in their own way.

That is how we were eventually able to finish the whole journey together.

I hope it was a good experience for everyone. ㅎㅎ

Gyeol (結) — Beyond the Chain (完)(END)

So, what did you think of our path(道)?

And how was the journey you walked together with us?

It has been an honor for us to reach the end of this road together, both as the Hackyboiz team and with all of you who followed along with the series.

Now, in August 2026, AI has advanced so rapidly that developing exploits for major vendors no longer feels quite as intimidating as it once did.

But even just last year, and into the beginning of this year, that barrier still felt pretty high to us.

That makes us even more grateful that we were able to make it all the way to the end of this journey.

With that, let’s hear some final thoughts from each member of the team!

• OUYA77

  Hi, this is OUYA77.

  To be honest, I never expected this project to wrap up with this much attention, so reaching this point feels pretty surreal. Personally, I had quite a few things to think about throughout the project, along with more than a few struggles(?). Still, when we first started, we put an image in our Notion page imagining, “This is what we’ll look like when we finally finish.”

  So I’m pretty happy that things actually turned out a little like the picture below. haha

  

  Timeline — Sometime in the first half of 2026

  ▼ Our expected faces after finishing the project (don’t open this)

  If I had to name one thing I wish we could have done better, it would be the finer details. Since the project stretched over a fairly long period of time, there were moments when the pace inevitably slowed down, and we weren’t able to polish every detail as much as I would have liked.

  True to the spirit of Wipeload, I originally wanted to take the primitives even further: refine them, optimize them, and spend more time on the engineering side of things.

  I guess I’ll just have to keep that one tucked away somewhere in the back of my mind. We also spent a lot of time thinking about whether we should release the exploits publicly. These days, with the help of AI, I don’t think writing an exploit is nearly as inaccessible as it once was. Of course, these exploits could potentially be used for malicious purposes — and no, we are absolutely not telling you to use them that way!!

  At the same time, though, there may be someone who studies these posts, learns from them, and eventually grows into an amazing security researcher.

  That is why we ultimately decided to take the leap and open up everything we had learned.

  Hopefully, by letting knowledge circulate and build upon itself, we can contribute in some small way to making the Internet a safer place.

  Alright, enough of the serious stuff.

  Once you’ve finished building a road, what are you supposed to do next?

  You’ve got to run down it at full speed, right?

  So for my next project (with new member), I’m thinking of moving on to Ghostwalk — and this time, we want to move through that road ghost-fast.

  Please look forward to it!!!!

  Spoiler: So… what exactly are you supposed to do after you pop calc? 👀

• ji9umi

  Hi, I’m ji9umi, and I was responsible for the Chrome V8 section in Stages 2 and 3 of the Wipeload Project. I was pretty busy both during the project and after it wrapped up, so I’d almost forgotten how long this journey actually was—but looking back at the photos, you can really tell just from the changing seasons 😇

  I had a chance to look into a similar Chrome 1-day vulnerability about two or three years ago, and as I mentioned in the introduction, things do feel a little easier now thanks to how quickly LLMs have evolved..! (Though it’s still far from easy)

  One thing I kept worrying about before joining this project was whether I’d end up just swapping out the shellcode in a public PoC without really understanding what was going on underneath. I hope the write-up I put together managed to convey that understanding clearly. Personally, there are still a few parts I wish I could have covered in more detail, so the project leaves me with a bit of unfinished business—but I hope the material is still useful to someone!!

  The Wipeload Project may be over, but my V8 journey definitely isn’t.

  To Be Continued… 😎

• gongjae

  Hello, I’m gongjae, and I was in charge of the Chrome Sandbox Escape for stages 5 and 6 of the Wipeload project! Did anyone happen to notice that my part actually took the longest to complete before writing this up? haha… Naturally, the gritty details of the Sandbox Escape weren’t fully laid out in Theori’s post either, and I honestly have no way of knowing if the approach I took is the “correct” answer. But whether it’s the right answer or not, I believe that brainstorming and imagining things in our own unique ways is incredibly helpful for learning.

  We are in an era where AI is rapidly advancing, reaching a point where finding vulnerabilities and writing exploits doesn’t require much human intervention anymore. Even so, I still think the most crucial human contribution lies in giving the AI direction.

  If I had just thrown a massive amount of tokens and time at an AI, this Sandbox Escape probably would have been finished in no time. Instead, I pitched the ideas I imagined directly to the AI, analyzed things together, and formulated a methodology. I think that collaborative process naturally blended into the stage 6 research post.. haha.

  Ultimately, I still believe that the drive to find solutions stems from human curiosity and a desire to know “why.” I do worry sometimes whether AI will eventually replace this aspect too, but rather than being overly pessimistic, I think it’s better to build up excitement about how we can tackle even more complex challenges alongside AI!!

  The main thing I want to say is this: I have massive respect for Theori—the starting point of this whole Wipeload journey—for pulling this off without any AI assistance. I want to keep pushing myself to become a researcher like them! 😎

• banda

  Hello, I’m banda, and I was responsible for the Kernel EoP sections in Steps 7 and 8 of the Wipeload project. Since I was in charge of the final stages, it really felt like the end of the project was getting closer as I worked through them. I’m also happy that the times we occasionally got together to study and just talk seemed to have a positive effect on the team. And this is a bit of a secret, but Catan was genuinely so much fun that I ended up bragging about the game afterward, introducing it to my friends, and playing it a few more times 😆

  There has already been a lot of discussion about AI, and one thought I had is that even though we are entering an era where vulnerabilities can increasingly be discovered with heavy reliance on AI, I still think the “first brain” ultimately has to be your own. And even when AI acts as your second brain, what you choose to ask that second brain still has to come from the first one.

  As one example, I did a bit of kernel bug hunting while working on Wipeload. There was one binary where, when I first ran AI and agent-based tools against it, they confidently concluded that there was no vulnerability. But then I remembered an MDL-related attack surface I had studied, decided to inspect that area myself, and ended up finding a vulnerability after all. That was one of the little behind-the-scenes stories from the project. 🙊 So I think spending time building concrete insight into vulnerabilities and studying specific attack surfaces will always be worthwhile.

  The Wipeload project itself may be over, but it also made me want to study exploit chaining much more deeply. I don’t think I’ll be able to casually scroll past Renderer or Sandbox vulnerabilities anymore whenever I come across them… haha. Personally, I owe Hackyboiz quite a lot, so I plan to stick around and keep publishing posts until the day 0-days finally dry up. Please continue to show the team lots of support. (Don’t worry, I think that day is going to take quite a while.)

  There are still plenty of topics waiting for you that you won’t find covered anywhere else! To Be Continued… 🫡

And finally, the Wipeload project received a lot of attention on X.

Much like the Gi-Seung-Jeon-Gyeol (起承轉結) structure of this final post, the series had been gradually building momentum, and things really took off with Wipeload Step 6. We received many shout-outs, emails, and messages from people who came across the series.

Thank you so much to everyone who took an interest in our work. :)

And please stay tuned for what Hackyboiz has coming next!

Hackyboiz is an offline study team based in the Seoul metropolitan area of South Korea. Unfortunately, this means it is difficult for us to directly collaborate or meet with individuals who are based overseas. ㅠ.ㅠ We hope you understand.

Thank you for reading! :)