<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on cristianrz</title><link>https://blog.cristianrz.eu.org/posts/</link><description>Recent content in Posts on cristianrz</description><generator>Hugo</generator><language>en</language><copyright>© 2026 cristianrz</copyright><lastBuildDate>Thu, 11 Jun 2026 10:24:39 +0100</lastBuildDate><atom:link href="https://blog.cristianrz.eu.org/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Reverse Engineering the Anticheat on a Private MMO Server</title><link>https://blog.cristianrz.eu.org/posts/active-anticheat/</link><pubDate>Thu, 11 Jun 2026 10:24:39 +0100</pubDate><guid>https://blog.cristianrz.eu.org/posts/active-anticheat/</guid><description>&lt;p&gt;I play on a private Aion server. For those unfamiliar, Aion is an MMO from 2009 that NCSoft has largely abandoned in the West, but a community of private servers keeps it alive. The server I play on uses a third-party anticheat called &lt;a href="https://active-ac.com"&gt;Active Anticheat&lt;/a&gt;, a commercial product sold to private server operators by a developer in Warsaw.&lt;/p&gt;
&lt;p&gt;I got curious about what it actually does to my machine. A few evenings with Wireshark, Procmon, Ghidra, and pefile later, here&amp;rsquo;s what I found.&lt;/p&gt;</description></item><item><title>An Analysis of GrapheneOS's Server Infrastructure</title><link>https://blog.cristianrz.eu.org/posts/grapheneos/</link><pubDate>Sun, 31 May 2026 00:00:00 +0000</pubDate><guid>https://blog.cristianrz.eu.org/posts/grapheneos/</guid><description>&lt;p&gt;I was poking around the &lt;a href="https://github.com/GrapheneOS/infrastructure"&gt;GrapheneOS infrastructure repo&lt;/a&gt; last week, just curious how they build things. First thing I noticed: every single server runs Arch Linux. DNS nodes, mail servers, the lot. You can verify it directly — every package list includes &lt;code&gt;pacman-contrib&lt;/code&gt; and &lt;code&gt;pacutils&lt;/code&gt;, which are Arch-specific and don&amp;rsquo;t exist on any other distro. The &lt;a href="https://github.com/GrapheneOS/infrastructure/blob/main/deploy-initial-vps"&gt;&lt;code&gt;deploy-initial-vps&lt;/code&gt; script&lt;/a&gt; checks for the Arch ISO before doing anything else: &lt;code&gt;ssh $remote '[[ $(grep IMAGE_ID /etc/os-release) = &amp;quot;IMAGE_ID=archlinux&amp;quot; ]]'&lt;/code&gt;. Arch on a server is unusual. I kept reading.&lt;/p&gt;</description></item><item><title>The Reboot Problem: Why Most Operating Systems Can't Defend Against a Compromised Root</title><link>https://blog.cristianrz.eu.org/posts/verified-boot/</link><pubDate>Fri, 22 May 2026 11:36:38 +0100</pubDate><guid>https://blog.cristianrz.eu.org/posts/verified-boot/</guid><description>&lt;p&gt;Assume malware has run on your machine and obtained root. After a reboot, is it still there? For most operating systems the answer is yes. The OS itself offers no structural resistance once root is obtained — it can write to system directories, replace binaries, install kernel modules, modify boot configuration. None of this requires exploiting a vulnerability. It&amp;rsquo;s just what root can do by design.&lt;/p&gt;
&lt;p&gt;The threat we&amp;rsquo;re reasoning about throughout is specifically this: malware that has obtained root and wants to survive a reboot at the OS level. Not keyloggers in &lt;code&gt;~/.bashrc&lt;/code&gt; — those are a different layer. Can the base OS be modified without detection, and will those modifications persist?&lt;/p&gt;</description></item><item><title>Console security principles and why PC is still catching up</title><link>https://blog.cristianrz.eu.org/posts/console-security/</link><pubDate>Sat, 30 Aug 2025 14:16:40 +0100</pubDate><guid>https://blog.cristianrz.eu.org/posts/console-security/</guid><description>&lt;p&gt;Consoles have a pretty remarkable track record. The PS5 and Xbox Series X have been out for years and neither has a public jailbreak. Meanwhile on PC, kernel-level cheats, rootkits, and firmware-level malware are a constant concern that entire security teams spend careers fighting.&lt;/p&gt;
&lt;p&gt;That&amp;rsquo;s not a coincidence. Console manufacturers made a set of deliberate architectural decisions that PC security has only started seriously borrowing from in the last decade — and some of it still hasn&amp;rsquo;t landed properly.&lt;/p&gt;</description></item><item><title>Securing Your Homelab: Navigating the Complexities of Remote Access and Trust</title><link>https://blog.cristianrz.eu.org/posts/securing-your-homelab/</link><pubDate>Mon, 13 Mar 2023 00:00:00 +0000</pubDate><guid>https://blog.cristianrz.eu.org/posts/securing-your-homelab/</guid><description>&lt;p&gt;Trying to set up my homelab and have it be reachable from the internet I had serious problems getting to where I wanted to be, although I never expected it was going to be that difficult.&lt;/p&gt;
&lt;p&gt;Being very pro-privacy pro-security my goals where:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Access my services from anywhere, including my phone&lt;/li&gt;
&lt;li&gt;Create trust between server and client that doesn&amp;rsquo;t involve 3rd parties, ideally trust on first use. Assume all middle-men are compromised.&lt;/li&gt;
&lt;li&gt;Have end to end encrypted connections.&lt;/li&gt;
&lt;li&gt;Clients can only talk to services once I know they are clients who I trust.&lt;/li&gt;
&lt;li&gt;Have a usable latency/bandwidth.&lt;/li&gt;
&lt;li&gt;Setup once/work forever. The kind of thing I would install on my mom&amp;rsquo;s devices so she can use my Nextcloud instance forever.&lt;/li&gt;
&lt;li&gt;Assume services security is flawed and they need a gatekeeper.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Now, the options I considered and why I don&amp;rsquo;t think any of them are viable.&lt;/p&gt;</description></item></channel></rss>