<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Obfuscation on 0xGently</title><link>https://0xgently.github.io/en/tags/obfuscation/</link><description>Recent content in Obfuscation on 0xGently</description><generator>Hugo</generator><language>en</language><copyright>Content is licensed under CC BY 4.0. © 0xGently</copyright><lastBuildDate>Tue, 27 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://0xgently.github.io/en/tags/obfuscation/index.xml" rel="self" type="application/rss+xml"/><item><title>Custom GetProcAddress</title><link>https://0xgently.github.io/en/posts/custom_getprocaddress/</link><pubDate>Tue, 27 Oct 2026 00:00:00 +0000</pubDate><guid>https://0xgently.github.io/en/posts/custom_getprocaddress/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;When developing with C or C++ on Windows systems, we generally use &lt;code&gt;GetProcAddress&lt;/code&gt; to call a function inside a DLL. The process is fundamentally simple: the DLL is loaded into memory with &lt;code&gt;LoadLibrary&lt;/code&gt;, and then the DLL&amp;rsquo;s handle value and the name of the searched function are passed to &lt;code&gt;GetProcAddress&lt;/code&gt;. But how exactly does this process work in the background? How does the operating system find the string value we provided inside a massive memory block and return its address to us? In this post, instead of using standard Windows APIs, we are writing our own &lt;code&gt;GetProcAddress&lt;/code&gt; function by parsing the memory structure of a PE file.&lt;/p&gt;</description></item><item><title>Custom GetModuleHandle</title><link>https://0xgently.github.io/en/posts/custom_getmodulehandle/</link><pubDate>Sun, 25 Oct 2026 00:00:00 +0000</pubDate><guid>https://0xgently.github.io/en/posts/custom_getmodulehandle/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Analyzing exactly how Windows APIs work under the hood gives us many new techniques and tactics when writing malware. In this post, we will explore how to implement one of the most frequently used APIs, &lt;code&gt;GetModuleHandle&lt;/code&gt;, from scratch without calling a single Windows API. Of course, one of the main reasons for doing this is to hide this heavily used function from the IAT (Import Address Table).&lt;/p&gt;
&lt;p&gt;As you know, &lt;code&gt;GetModuleHandle&lt;/code&gt; returns the base memory address of a loaded module given its DLL name. What it actually does is quite straightforward: it scans a list of loaded modules maintained by the OS loader for each process. This list resides inside the Process Environment Block (PEB) structure. The focus of this post will be to show, step by step, how to manually access the PEB and parse this list.&lt;/p&gt;</description></item><item><title>IPv4/IPv6 DeObfuscation</title><link>https://0xgently.github.io/en/posts/%C4%B1pv4_deobf/</link><pubDate>Fri, 10 Apr 2026 00:00:00 +0000</pubDate><guid>https://0xgently.github.io/en/posts/%C4%B1pv4_deobf/</guid><description>&lt;h2 id="ipv4v6-deobfuscation"&gt;IPv4/v6 DeObfuscation&lt;/h2&gt;
&lt;p&gt;In this post, we will examine how a network configuration function, which looks completely ordinary from the outside, is transformed into a shellcode decoder. Our goal is to understand the attacker&amp;rsquo;s mindset and design our defensive systems to catch these types of &amp;ldquo;normal-looking anomalies.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: You can find the entirety of the code explained in this text at &lt;a href="https://github.com/0xGently/malware-development-library/tree/main/Payload-Encryption-and-Obfuscation/06-IPv4_IPv6_DeObf"&gt;malware-development-library&lt;/a&gt; Furthermore, once you establish the logic of this topic and examine the full version of the code, you can also construct DeObfuscation processes applied to other techniques. They are pretty much the same anyway; you only need to make a few modifications, that is all.&lt;/p&gt;</description></item><item><title>IPv4/IPv6 Obfuscation</title><link>https://0xgently.github.io/en/posts/%C4%B1pv4_obf/</link><pubDate>Thu, 05 Feb 2026 00:00:00 +0000</pubDate><guid>https://0xgently.github.io/en/posts/%C4%B1pv4_obf/</guid><description>&lt;h2 id="ipv4ipv6-obfuscation"&gt;IPv4/IPv6 Obfuscation&lt;/h2&gt;
&lt;p&gt;In the world of cybersecurity, when we want to hide data, we generally have two fundamental paths ahead of us: we either encrypt the data directly (such as AES, RC4, or XOR) or we obfuscate it.&lt;/p&gt;
&lt;p&gt;When developing software, obfuscating the code sometimes plays a critical role not only in protecting intellectual property but also in bypassing security mechanisms. For example, suppose we have a shellcode and we want to hide it. Although encryption is the first solution that comes to mind, it might not always be the smartest route. This is because encrypted data causes the &lt;strong&gt;entropy (randomness rate)&lt;/strong&gt; in that specific section of the file to skyrocket, and this situation immediately catches the radar of security analysts or AV/EDR solutions. At this point, obfuscating without drawing attention transforms into a much more logical alternative.&lt;/p&gt;</description></item></channel></rss>