<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Low Level System Defense on Prepakis Georgios | Kernelstub | Security Researcher</title><link>https://blog.kernelstub.dev/tags/low-level-system-defense/</link><description>Recent content in Low Level System Defense on Prepakis Georgios | Kernelstub | Security Researcher</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sat, 25 Oct 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.kernelstub.dev/tags/low-level-system-defense/index.xml" rel="self" type="application/rss+xml"/><item><title>From Bits to Breaks A Low Level System Exploitation and Defense</title><link>https://blog.kernelstub.dev/posts/from-bits-to-breaks-a-low-level-system-exploitation-and-defense/</link><pubDate>Sat, 25 Oct 2025 00:00:00 +0000</pubDate><guid>https://blog.kernelstub.dev/posts/from-bits-to-breaks-a-low-level-system-exploitation-and-defense/</guid><description>&lt;h2 id="introduction-and-scope"&gt;Introduction and Scope&lt;/h2&gt;
&lt;p&gt;Here&amp;rsquo;s the core question driving this whole project: how do software and hardware actually interact once you strip away the abstraction layers that normally hide the messy details from you? Compilers, operating systems, and runtimes exist precisely so you can forget about page tables, cache lines, and instruction pipelines while you get work done. Attackers, and the researchers trying to stay ahead of them, don&amp;rsquo;t get that luxury. Every exploit involving memory corruption, firmware, or a leaky microarchitectural feature lives exactly at that seam between the code you wrote and the silicon actually running it. This research examines that seam systematically, aiming to produce techniques reproducible enough to be useful, rigorous enough to be academically sound, and constrained enough to stay ethically defensible.&lt;/p&gt;</description></item></channel></rss>