Ruby#

CTF: VulnByDefault CTF
Challenge: Ruby
Category: Misc / Reverse Engineering
Difficulty: Medium
Flag: VBD{82776878}

1. Challenge Overview#

The challenge prompt was essentially:

Play the game and get the flag.

At first glance, the challenge name Ruby suggested a programming-language challenge or maybe a scripting puzzle. That turned out to be a misdirection.

The provided files were inside:

1
1. ctf/new/dist/dist/
2
â”œâ”€â”€ challenge.schem
3
â””â”€â”€ MyWorld/

That immediately changed the direction of the solve. A .schem file plus a full Minecraft world save strongly suggested that the real target was not source code, but a Minecraft-based logic or redstone system.

2. Initial Recon#

2.1 Provided Artifacts#

The two important artifacts were:

challenge.schem
MyWorld/

Inside MyWorld, the key file was level.dat, which identified the world as:

1
LevelName: Computer v2 by mattbatwings

That was the first major clue.

2.2 What This Meant#

This was not a normal Minecraft map challenge where you explore, click buttons, and read signs. It was a challenge built on top of a redstone computer.

So the real task became:

Identify the computer architecture
Recover the program stored in the schematic
Reverse the program logic
Derive the numeric flag

3. Identifying the Architecture#

The level.dat string Computer v2 by mattbatwings pointed directly to Mattbatwings’ public redstone CPU project.

Using that clue, the architecture was identified as:

1
BatPU-2

From the public project materials, the following details were recovered:

16-bit instructions
1024 instruction memory slots
Separate data memory
An assembler with mnemonics like:
- nop, hlt, add, sub, nor, and, xor, rsh
- ldi, adi, jmp, brh, cal, ret, lod, str
I/O ports mapped in the 240-255 range
The number display is controlled through port 250

That was enough to start decoding the program stored in challenge.schem.

4. Understanding the Schematic#

4.1 Why the `.schem` File Matters#

The schematic was not just a build file for decoration. It contained the machine’s instruction ROM encoded as redstone components.

The BatPU-2 schematic generator writes each 16-bit instruction using repeaters and wool blocks:

repeater = bit 1
wool = bit 0

The program memory layout from the upstream generator made it possible to reconstruct the exact instruction stream.

4.2 Decoding Result#

After reconstructing the address layout and reading the bit columns from the schematic, the ROM contained:

1024 total instruction slots
only 37 non-zero instructions

That was a strong sign that this was a small deterministic computation rather than an actual game that needed to be played manually.

5. Recovered Program Logic#

The important non-zero instructions reduced to two stages:

Stage 1: Initialize Data#

The program loads eight constants and stores them in data memory.

Recovered values:

1
55, 101, 41, 100, 125, 57, 35, 109

The relevant instruction pattern looked like this in behavior:

1
RAM[0] = 55
2
RAM[1] = 101
3
RAM[2] = 41
4
RAM[3] = 100
5
RAM[4] = 125
6
RAM[5] = 57
7
RAM[6] = 35
8
RAM[7] = 109

Stage 2: Process Pairs and Display Output#

The second part of the program loops over those values in pairs:

1
(RAM[0], RAM[1])
2
(RAM[2], RAM[3])
3
(RAM[4], RAM[5])
4
(RAM[6], RAM[7])

For each pair, it:

loads the first value
loads the second value
XORs them
writes the result to the number-display port

6. Important Reversal Detail#

The key thing that made the solve click was interpreting the BatPU-2 STR instruction correctly.

In this ISA:

1
STR base src offset

means:

1
memory[base + offset] = src

So when the disassembly showed instructions equivalent to:

1
LDI r1 0
2
LDI r2 55
3
STR r1 r2 0

that does not mean “store into address 55” or “write to register 55”.

It means:

1
RAM[0] = 55

Once that operand order was interpreted correctly, the program became straightforward.

7. Manual Emulation#

Now compute the XOR for each adjacent pair.

Pair 1#

1
55 ^ 101 = 82

Pair 2#

1
41 ^ 100 = 77

Pair 3#

1
125 ^ 57 = 68

Pair 4#

1
35 ^ 109 = 78

So the four displayed outputs are:

1
82 77 68 78

Concatenating them gives:

1
82776878

8. Final Flag#

1
VBD{82776878}

9. Why This Challenge Was Tricky#

This challenge was tricky for a few reasons:

The name Ruby pushes you toward the wrong ecosystem.
The prompt says “Play the game,” which suggests manual interaction.
The actual payload is hidden inside a Minecraft redstone CPU schematic.
You need to recognize the architecture before any of the files make sense.
The solve depends on understanding a custom ISA, especially the operand semantics of LOD and STR.

In reality, this was a compact ROM-reversing challenge disguised as a Minecraft world.

10. Short Solve Summary#

Inspect the provided files and notice challenge.schem plus MyWorld/.
Parse level.dat and identify Computer v2 by mattbatwings.
Recognize the machine as BatPU-2.
Reconstruct the 16-bit ROM from the schematic layout.
Disassemble the 37 non-zero instructions.
Recover the initialized RAM values: 55, 101, 41, 100, 125, 57, 35, 109.
Observe that the loop XORs adjacent pairs and writes the results to the number display.
Compute outputs: 82, 77, 68, 78.
Concatenate them to get 82776878.
Submit VBD{82776878}.

11. Reproduction Snippet#

Once the values are known, the flag derivation is just:

1
vals = [55, 101, 41, 100, 125, 57, 35, 109]
2
outs = [vals[i] ^ vals[i + 1] for i in range(0, 8, 2)]
3
print(outs)                       # [82, 77, 68, 78]
4
print(''.join(map(str, outs)))    # 82776878

12. Takeaway#

The challenge was solved without “playing” the Minecraft world at all. The faster route was to treat the world and schematic as a serialized program, recover the BatPU-2 machine code, and emulate the tiny algorithm by hand.

That turned a misleading misc challenge into a clean reverse-engineering problem.