<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MrN1gativ3</title><link>https://mrn1gativ3.github.io/</link><description>Recent content on MrN1gativ3</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 26 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://mrn1gativ3.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Heap Exploitation Part 3</title><link>https://mrn1gativ3.github.io/posts/heapexp3/</link><pubDate>Thu, 26 Sep 2024 00:00:00 +0000</pubDate><guid>https://mrn1gativ3.github.io/posts/heapexp3/</guid><description>&lt;h3 id="intro"&gt;Intro&lt;/h3&gt;
&lt;p&gt;In this post I will walk through a small heap-overflow challenge and show how the overflow reaches a heap-resident function pointer. This is a toy binary, but it is a good lab for understanding chunk adjacency, overwrite distance, and one very important exploitation detail: why a &lt;strong&gt;partial pointer overwrite&lt;/strong&gt; is enough in this program.&lt;/p&gt;
&lt;hr&gt;
&lt;h3 id="binary-info"&gt;Binary Info&lt;/h3&gt;
&lt;p&gt;&lt;img src="Screenshot_at_2024-09-26_12-50-04.png" alt="Screenshot at 2024-09-26 12-50-04.png"&gt;&lt;/p&gt;
&lt;p&gt;For this write-up I recompiled the binary from source and disabled PIE and the stack canary. Disabling those protections keeps function addresses stable between runs and makes the control-flow goal easier to explain.&lt;/p&gt;</description></item><item><title>No File, No Path, Still Running: Inside Linux Fileless Execution</title><link>https://mrn1gativ3.github.io/posts/filelessexec/</link><pubDate>Thu, 26 Sep 2024 00:00:00 +0000</pubDate><guid>https://mrn1gativ3.github.io/posts/filelessexec/</guid><description>&lt;h2 id="where-it-all-started"&gt;Where It All Started&lt;/h2&gt;
&lt;p&gt;Honestly, I&amp;rsquo;m not even sure how I ended up here.
It started with process injection on Linux something I was poking at in my spare time between work. One thing led to another, and at some point I searched online and stumbled across something called Linux fileless malware. I&amp;rsquo;d heard of fileless attacks on Windows, but Linux? That caught my attention. I thought I knew what it meant. Run something without dropping a file. Simple.
Except it wasn&amp;rsquo;t.
The more I read, the more questions I had. Where do the bytes actually live if there&amp;rsquo;s no file? What does the kernel think is happening? Which syscall actually triggers execution and why does it matter which one? I&amp;rsquo;d answer one question and three more would show up. That&amp;rsquo;s usually the sign that something is worth digging into properly.
The articles I found were good but incomplete most covered one angle, one technique, one tool. Nobody had written the thing I actually wanted to read: a complete walkthrough of how this works at the kernel level, from the first syscall to a fully running in-memory process, with explanations for what&amp;rsquo;s happening at each step and why.
So I wrote it myself.
This series is the result of a few months of going through kernel source code, running experiments, and building a mental model that finally felt solid. It&amp;rsquo;s not a malware analysis and it&amp;rsquo;s not a threat intel report. It&amp;rsquo;s just me trying to understand something properly and documenting what I found the mechanics, the internals, and why this technique is considerably more interesting than the one-line definition suggests.&lt;/p&gt;</description></item><item><title>Heap Exploitation Part 2</title><link>https://mrn1gativ3.github.io/posts/heapexp2/</link><pubDate>Fri, 16 Aug 2024 00:00:00 +0000</pubDate><guid>https://mrn1gativ3.github.io/posts/heapexp2/</guid><description>&lt;h3 id="intro"&gt;Intro&lt;/h3&gt;
&lt;p&gt;In the first part I covered the allocator building blocks: arenas, chunks, metadata, and bins. In this post I want to connect those pieces into the actual allocation and free paths you will see while debugging a process or reading glibc source.&lt;/p&gt;
&lt;p&gt;The most important thing to keep in mind is that glibc does not have one single &amp;ldquo;malloc path&amp;rdquo; or one single &amp;ldquo;free list&amp;rdquo;. The path depends on request size, tcache state, arena state, and the exact glibc version.&lt;/p&gt;</description></item><item><title>Heap Exploitation Part 1</title><link>https://mrn1gativ3.github.io/posts/heapexp1/</link><pubDate>Mon, 10 Jun 2024 00:00:00 +0000</pubDate><guid>https://mrn1gativ3.github.io/posts/heapexp1/</guid><description>&lt;h2 id="intro"&gt;Intro&lt;/h2&gt;
&lt;p&gt;This is the first part of the heap exploitation series. In this post I will build a clean mental model of the glibc allocator before getting into bugs and primitives. The goal here is not to memorize every macro in &lt;code&gt;malloc.c&lt;/code&gt;, but to understand the objects that keep showing up in heap write-ups: arenas, chunks, the top chunk, and the different bins.&lt;/p&gt;
&lt;p&gt;One important note before we start: glibc heap internals are version-sensitive. Constants, tcache behavior, and even which code path gets hit first can change between releases, so treat the structures in this post as the model you should verify against the exact glibc version on your target.&lt;/p&gt;</description></item></channel></rss>