Six Faces, Twenty-Four Bytes: Reversing S01den's Pocket-Cube Crackme

A 14 KB Linux ELF whose only imports it actually calls in its logic are strcpy, puts and strlen turns out to be a complete 2×2×2 Rubik's-cube engine: your "flag" is a string of face-turn letters, the binary spins a scrambled cube stored in .data, and it prints G00d flag! only when all six faces come out solid. This is the full teardown — the move tables recovered sticker-by-sticker under gdb, a byte-exact Python port, and the eight-move solution the binary confirms.

The target

The artefact is cm_rb_easy, pulled from crackmes.one (S01den's "cube", Linux/x86-64, listed difficulty 4). Vital statistics:

$ sha256sum cm_rb_easy
3e707363e4b7299268a916f0214127f825c97d1bb7cec264d235d28ae385c0d7  cm_rb_easy
$ wc -c cm_rb_easy
14456 cm_rb_easy
$ file cm_rb_easy
ELF 64-bit LSB pie executable, x86-64, dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2, ... stripped

It is a position-independent executable, dynamically linked against glibc, built with GCC 12.1.0 (from the .comment section), and stripped of local symbols. The dynamic symbol table is tiny — the whole program leans on three libc functions it actually calls in its logic (strcpy/puts/strlen), plus CRT __libc_start_main and stack-protector __stack_chk_fail:

$ readelf -sW cm_rb_easy | grep FUNC
  __libc_start_main@GLIBC_2.34
  strcpy@GLIBC_2.2.5
  puts@GLIBC_2.2.5
  strlen@GLIBC_2.2.5
  __stack_chk_fail@GLIBC_2.4

No printf, no scanf, no crypto, no ptrace. Everything interesting is hand-rolled inside main and two helper functions. That import list alone tells you the logic is a self-contained byte-shuffle over a fixed buffer — there is no I/O beyond a single puts verdict.

First impressions

strings is unusually honest here:

[!] Usage: ./cmRubiks flag
[!] The flag is too long...
[!] Bad flag!
[*] G00d flag!
oobvbbjBrorvjBvrjBrvjBob

Two things jump out. The internal name is cmRubiks — a Rubik's cube. And there is a stray 24-byte string, oobvbbjBrorvjBvrjBrvjBob, sitting in the data. Twenty-four is exactly the number of facelets (stickers) on a 2×2×2 "pocket" cube: six faces × four stickers. The alphabet of that string is {o, b, v, j, B, r} — six symbols, and if you read them as French colour initials (S01den is a French author) they are orange, bleu, vert, jaune, Blanc, rouge. Six colours, four of each. That is a legal cube colouring.

A quick ltrace shows the runtime shape without any disassembly:

$ ltrace -s 40 ./cm_rb_easy ABCDEFGHIJKLMNOPQRSTUVWX
strlen("ABCDEFGHIJKLMNOPQRSTUVWX")  = 24
strcpy(0x7fff..., "ABCDEFGHIJKLMNOPQRSTUVWX") = 0x7fff...
strlen("ABCDEFGHIJKLMNOPQRSTUVWX")  = 24
strlen("ABCDEFGHIJKLMNOPQRSTUVWX")  = 24
strlen(...)                          = 24     ← repeated once per character
...

The flag is copied to a stack buffer, then a loop runs once per character (each iteration re-evaluates strlen as the loop bound — an un-hoisted for (i=0; i < strlen(s); i++)). No output during the loop; the single puts at the end is the whole verdict. Initial hypothesis: each flag character is a cube move; the loop applies moves to a scrambled cube; success means the cube ends solved. The rest of the work is confirming that and recovering the exact move semantics.

Static pass: the shape of main

Disassembly is objdump -d -M intel cm_rb_easy. The function at 0x122f is main. Its prologue and gatekeeping (addresses from the objdump listing):

1257: cmp   DWORD PTR [rbp-0xa4],0x1      ; argc <= 1 ?
125e: jg    1279
1260: lea   rax,[rip+0xd9d]  # 2004       ; "[!] Usage: ./cmRubiks flag"
126a: call  1040 <puts@plt>               ;   -> print, return 0
1279: mov   rax,[rbp-0xb0]                 ; argv
1284: add   rax,0x8                        ; argv[1]
128a: call  1050 <strlen@plt>
128f: cmp   rax,0x63                        ; len <= 99 ?
1293: jbe   12ae
1295: lea   rax,[rip+0xd83]  # 201f        ; "[!] The flag is too long..."
12ae: mov   rdx,[argv[1]]
12bc: lea   rax,[rbp-0x80]                  ; dst = stack buffer
12c6: call  1030 <strcpy@plt>              ; strcpy(buf, argv[1])

So: require an argument, require len(flag) ≤ 99, copy it to a 128-byte stack buffer at rbp-0x80. Then the move loop begins. The loop body reads one character and dispatches on it:

12ee: mov   eax,[rbp-0x94]                 ; i
12f6: movzx eax,BYTE PTR [rbp+rax-0x80]    ; c = buf[i]
12fe: sub   eax,0x42                        ; c - 'B'
1301: cmp   eax,0x33                         ; > 51 ?  (unsigned)
1304: ja    1b02                             ;   yes -> skip (default)
130c: lea   rdx,[rax*4]
1314: lea   rax,[rip+0xd3d]  # 2058          ; jump-table base
131b: mov   eax,[rdx+rax]                     ; table[c-'B']
1320: lea   rdx,[rip+0xd31]  # 2058
1327: add   rax,rdx                           ; base + rel32
132a: jmp   rax                               ; computed goto

This is a textbook GCC switch: the character is offset by 'B' (0x42), bounds-checked against 0x33 = 51 inclusive (52 possible cases), and used to index a table of 32-bit self-relative offsets at 0x2058. Anything out of range — or any in-range character whose table entry is the default — jumps to 0x1b02, which simply advances the loop counter. In other words, unknown characters are silently ignored.

Decoding the jump table

The table is 52 int32 entries at file offset 0x2058 (for this region the file offset equals the virtual address, which I confirmed by reading the raw bytes and matching objdump). Each entry is added to 0x2058 to get the handler address. A five-line decoder:

import struct
data = open('cm_rb_easy','rb').read()
base = 0x2058
for i in range(52):
    e = struct.unpack('<i', data[base+i*4: base+i*4+4])[0]
    h = (base + e) & 0xffffffff
    if h != 0x1b02:                       # 0x1b02 == default (ignore)
        print(f"{chr(0x42+i)!r} -> 0x{h:04x}")

Output — exactly twelve live cases:

char	c−'B'	handler	char	c−'B'	handler
B	0	0x1868	b	32	0x18fe
D	2	0x19b7	d	34	0x1a4d
F	4	0x147b	f	36	0x1511
L	10	0x1719	l	42	0x17af
R	16	0x15ca	r	48	0x1660
U	19	0x132c	u	51	0x13c2

That is the standard cube move alphabet: U D L R F B (Up, Down, Left, Right, Front, Back) plus their lowercase counterparts. Every other byte is a no-op. The default target 0x1b02 is the loop's i++.

The cube in memory

The move handlers all read and write a 24-byte global that lives in .data:

$ objdump -s -j .data cm_rb_easy
 4040 40400000 00000000 6f6f6276 62626a42   @@......oobvbbjB
 4050 726f7276 6a427672 6a427276 6a426f62   rorvjBvrjBrvjBob

The 24 cube bytes are at 0x4048; the eight bytes at 0x4040 are an unused qword (a self-referential relocation, referenced by nothing in the code). The cube's six faces are four consecutive bytes each. By watching which four-byte block each move rotates in place (the tell-tale [o2,o0,o3,o1] pattern — (old[2],old[0],old[3],old[1]) — from the face helper, below), I pinned the layout:

face	byte indices	.data address	initial (scramble)
U (Up)	0–3	0x4048	o o b v
B (Back)	4–7	0x404c	b b j B
F (Front)	8–11	0x4050	r o r v
D (Down)	12–15	0x4054	j B v r
L (Left)	16–19	0x4058	j B r v
R (Right)	20–23	0x405c	j B o b

So the binary boots with an already-scrambled cube baked into .data, and the flag is the sequence of turns that unscrambles it.

The face helper (0x1169): rotate four stickers

Every move calls 0x1169 on the base address of one face. Verbatim first half:

1188: mov    rax,QWORD PTR [rbp-0x18]   ; rax = p (face base)
118c: movzx  eax,BYTE PTR [rax]         ; t0 = p[0]
118f: mov    BYTE PTR [rbp-0xa],al
1196: movzx  eax,BYTE PTR [rax+0x1]     ; t1 = p[1]
119a: mov    BYTE PTR [rbp-0x9],al
11a1: add    rax,0x2
11a5: movzx  edx,BYTE PTR [rax]         ; edx = p[2]
11a8: mov    rax,QWORD PTR [rbp-0x18]
11ac: mov    BYTE PTR [rax],dl          ; p[0] = p[2]

The remaining stores (0x11b6–0x11e3) finish the shuffle. The net effect on the four bytes p[0..3] is:

p'[0] = p[2]   p'[1] = p[0]   p'[2] = p[3]   p'[3] = p[1]

That is a 90° rotation of a 2×2 face's four corner-stickers — the cycle (0 2 3 1). Call it rot4. There is a sibling at 0x11fc that calls rot4 three times (a 270° / inverse face spin); it is used by moves whose side-cycle logic is written the other way around.

A move handler in full: U (0x132c)

Each uppercase handler does two things: it rot4-spins its own face, and it hand-cycles the eight side-stickers that a face turn drags around from the four neighbouring faces. Here is U, verbatim, annotated ([rip→0xXXXX] is the absolute .data byte the instruction touches):

132c: movzx eax,[rip→0x4050]   ; save a = F[0]  (cube[8])
1333: mov   [rbp-0x82],al
1339: movzx eax,[rip→0x4051]   ; save b = F[1]  (cube[9])
1340: mov   [rbp-0x81],al
1346: movzx eax,[rip→0x405c]   ; cube[8]  = R[0] (cube[20])
134d: mov   [rip→0x4050],al
1353: movzx eax,[rip→0x405d]   ; cube[9]  = R[1] (cube[21])
135a: mov   [rip→0x4051],al
1360: movzx eax,[rip→0x404c]   ; cube[20] = B[0] (cube[4])
1367: mov   [rip→0x405c],al
136d: movzx eax,[rip→0x404d]   ; cube[21] = B[1] (cube[5])
1374: mov   [rip→0x405d],al

…and the tail, which pulls L into B, the saved F pair into L, then spins the U face:

137a: movzx eax,[rip→0x4058]   ; cube[4]  = L[0] (cube[16])
1381: mov   [rip→0x404c],al
1387: movzx eax,[rip→0x4059]   ; cube[5]  = L[1] (cube[17])
138e: mov   [rip→0x404d],al
1394: movzx eax,[rbp-0x81]     ; cube[17] = saved b (old F[1])
139b: mov   [rip→0x4059],al
13a1: movzx eax,[rbp-0x82]     ; cube[16] = saved a (old F[0])
13a8: mov   [rip→0x4058],al
13ae: lea   rax,[rip→0x4048]   ; rot4(&U face)
13b8: call  1169

Read as a permutation, U cycles the top-row sticker pairs of the four side faces F ← R ← B ← L ← F and rotates the U face. The prime move u (0x13c2) is the identical body wrapped in for (j=0; j<=2; j++) — three applications, i.e. U⁻¹:

13c2: mov   DWORD PTR [rbp-0x90],0x0   ; j = 0
13cc: jmp   1469
13d1: ... (same 8 side-swaps as U + rot4) ...
1462: add   DWORD PTR [rbp-0x90],0x1    ; j++
1469: cmp   DWORD PTR [rbp-0x90],0x2    ; j <= 2 ?
1470: jle   13d1

So the whole move set is: uppercase = one quarter-turn, lowercase = three quarter-turns = the inverse. Elegant, and it means there are no half-turn opcodes — UU is how you write a 180° turn.

Recovering all twelve permutations under gdb

Rather than hand-decode the side-cycle for all six faces from assembly, I let the binary tell me. The moves operate on distinguishable-by-position data only if the cube bytes are distinct, so I injected the identity 0,1,…,23 into the live cube, ran exactly one move, and read the result. Because the sandbox forbids disabling ASLR (set disable-randomization returns Operation not permitted), I resolve the PIE base from /proc/pid/mappings at runtime and run one move per gdb process. The extractor:

# extract_one.py — gdb -q -nx -batch -x extract_one.py --args ./cm_rb_easy <MOVE>
import gdb
def base_addr():
    out = gdb.execute("info proc mappings", to_string=True)
    for line in out.splitlines():
        parts = line.split()
        if parts and parts[-1].endswith("cm_rb_easy"):
            return int(parts[0], 16)
    raise RuntimeError("base not found")

gdb.execute("starti")
b = base_addr()
gdb.execute("break *0x%x" % (b + 0x12cb))   # after strcpy, before the move loop
gdb.execute("break *0x%x" % (b + 0x1b27))   # after the loop, before the face check
gdb.execute("continue")
inf  = gdb.selected_inferior()
cube = b + 0x4048
inf.write_memory(cube, bytes(range(24)))    # inject identity 0..23
gdb.execute("continue")
print("PERM:", list(bytes(inf.read_memory(cube, 24))))
gdb.execute("kill")

Driven over the alphabet, this yields, for each move M, the gather permutation P such that new[i] = old[P[i]]:

U [2,0,3,1, 16,17,6,7, 20,21,10,11, 12,13,14,15, 8,9,18,19, 4,5,22,23]
D [0,1,2,3, 4,5,22,23, 8,9,18,19, 14,12,15,13, 16,17,6,7, 20,21,10,11]
L [7,1,5,3, 4,14,6,12, 0,9,2,11, 8,13,10,15, 18,16,19,17, 20,21,22,23]
R [0,9,2,11, 3,5,1,7, 8,13,10,15, 12,6,14,4, 16,17,18,19, 22,20,23,21]
F [0,1,19,17, 4,5,6,7, 10,8,11,9, 22,20,14,15, 16,12,18,13, 2,21,3,23]
B [21,23,2,3, 6,4,7,5, 8,9,10,11, 12,13,16,18, 1,17,0,19, 20,15,22,14]
u [1,3,0,2, 20,21,6,7, 16,17,10,11, 12,13,14,15, 4,5,18,19, 8,9,22,23]
d [0,1,2,3, 4,5,18,19, 8,9,22,23, 13,15,12,14, 16,17,10,11, 20,21,6,7]
l [8,1,10,3, 4,2,6,0, 12,9,14,11, 7,13,5,15, 17,19,16,18, 20,21,22,23]
r [0,6,2,4, 15,5,13,7, 8,1,10,3, 12,9,14,11, 16,17,18,19, 21,23,20,22]
f [0,1,20,22, 4,5,6,7, 9,11,8,10, 17,19,14,15, 16,3,18,2, 13,21,12,23]
b [18,16,2,3, 5,7,4,6, 8,9,10,11, 12,13,23,21, 14,17,15,19, 20,0,22,1]

Cross-check against the U handler I decoded by hand: P_U[8]=20, P_U[9]=21 (F's top pair comes from R), P_U[20]=4, P_U[21]=5 (R from B), P_U[4]=16, P_U[5]=17 (B from L), P_U[16]=8, P_U[17]=9 (L from F), and P_U[0..3]=[2,0,3,1] (the rot4 spin of the U face). The empirical table and the disassembly agree exactly.

The move algebra is a genuine cube group. A one-liner confirms every generator has order 4 and that lowercase is the inverse of uppercase:

$ python3 -c '...'      # apply on identity 0..23
U  U;u=id True   U^4=id True   u==UUU True
D  U;u=id True   U^4=id True   u==UUU True
L  U;u=id True   U^4=id True   u==UUU True
R  U;u=id True   U^4=id True   u==UUU True
F  U;u=id True   U^4=id True   u==UUU True
B  U;u=id True   U^4=id True   u==UUU True

The 4-cycle a face turn induces on its neighbours is the whole geometric story. Here is U dragging the top rows of the four side faces around, one hop per beat:

The win condition (0x1b27 onward)

After the loop, main checks all six faces for uniformity. The check is six copies of the same double loop; the first one (over the F face at 0x4050) reads:

1b3b: movzx eax,[rip→0x4050]   ; ref = F[0]
1b42: mov   [rbp-0x95],al
1b60: mov   eax,[rbp-0x88]     ; j (0..1)
1b68: mov   edx,[rbp-0x8c]     ; i (0..1)
1b71: add   rdx,rdx            ; 2*i
1b74: add   rdx,rax            ; 2*i + j
1b77: lea   rax,[rip→0x4050]   ; face base
1b7e: add   rax,rdx
1b81: movzx eax,[rax]          ; face[2*i+j]
1b84: cmp   [rbp-0x95],al      ; == ref ?
1b8a: je    1ba5              ;   ok
1b8c: lea   rax,[rip→0x203b]   ; "[!] Bad flag!"
1b96: call  1040 <puts@plt>
1ba0: jmp   1e88              ;   return 0

Each face's four stickers are compared to that face's first sticker; a single mismatch prints [!] Bad flag! and returns. The six faces are checked in the order F, U, B, D, L, R (0x4050, 0x4048, 0x404c, 0x4054, 0x4058, 0x405c). If all six survive, execution falls through to 0x1e74:

1e74: lea   rax,[rip→0x2049]   ; "[*] G00d flag!"
1e7e: call  1040 <puts@plt>

There is no secret comparison against a stored string, no hidden key. Solved literally means solved: every face a single colour. The initial .data scramble is the puzzle; the flag is any turn sequence that solves it.

The Python re-implementation

Here is the ground-truth port. It encodes the six face slices, the twelve gather permutations, the baked-in scramble, and the uniformity check — nothing else:

#!/usr/bin/env python3
"""Faithful re-implementation of S01den's pocket-cube crackme (cm_rb_easy).

24-byte cube at .data:0x4048.  Six faces of four stickers:
    U=0..3  B=4..7  F=8..11  D=12..15  L=16..19  R=20..23
Each move is a GATHER permutation P: new[i] = old[P[i]].  Uppercase = one
quarter turn, lowercase = its inverse (the binary runs the body three times).
Tables recovered by injecting identity bytes 0..23 into the live cube under
gdb and reading the result after one move."""

PERM = {
 'U': [2,0,3,1,16,17,6,7,20,21,10,11,12,13,14,15,8,9,18,19,4,5,22,23],
 'D': [0,1,2,3,4,5,22,23,8,9,18,19,14,12,15,13,16,17,6,7,20,21,10,11],
 'L': [7,1,5,3,4,14,6,12,0,9,2,11,8,13,10,15,18,16,19,17,20,21,22,23],
 'R': [0,9,2,11,3,5,1,7,8,13,10,15,12,6,14,4,16,17,18,19,22,20,23,21],
 'F': [0,1,19,17,4,5,6,7,10,8,11,9,22,20,14,15,16,12,18,13,2,21,3,23],
 'B': [21,23,2,3,6,4,7,5,8,9,10,11,12,13,16,18,1,17,0,19,20,15,22,14],
 'u': [1,3,0,2,20,21,6,7,16,17,10,11,12,13,14,15,4,5,18,19,8,9,22,23],
 'd': [0,1,2,3,4,5,18,19,8,9,22,23,13,15,12,14,16,17,10,11,20,21,6,7],
 'l': [8,1,10,3,4,2,6,0,12,9,14,11,7,13,5,15,17,19,16,18,20,21,22,23],
 'r': [0,6,2,4,15,5,13,7,8,1,10,3,12,9,14,11,16,17,18,19,21,23,20,22],
 'f': [0,1,20,22,4,5,6,7,9,11,8,10,17,19,14,15,16,3,18,2,13,21,12,23],
 'b': [18,16,2,3,5,7,4,6,8,9,10,11,12,13,23,21,14,17,15,19,20,0,22,1],
}

SCRAMBLE = "oobvbbjBrorvjBvrjBrvjBob"       # .data:0x4048 initial state
FACES = {'U':(0,4),'B':(4,8),'F':(8,12),'D':(12,16),'L':(16,20),'R':(20,24)}

def apply_move(state, m):
    p = PERM[m]
    return bytes(state[p[i]] for i in range(24))

def run(moves, start=None):
    s = bytes((start or SCRAMBLE), 'latin1')
    for m in moves:
        s = apply_move(s, m)
    return s

def is_solved(state):
    return all(len(set(state[a:b])) == 1 for a, b in FACES.values())

def verdict(moves):
    return "G00d flag!" if is_solved(run(moves)) else "Bad flag!"

Differential test against the binary

To prove the port is faithful — not merely plausible — I compared the final 24-byte cube state produced by my apply_move chain against the binary's actual .data:0x4048 after the loop, read under gdb (dump_state.py breaks at 0x1b27 and prints the buffer). Twelve random move strings of length 1–14:

# difftest.py (core)
import random, subprocess, cube
ALPHA = "UDLRFBudlrfb"
def binary_state(moves):
    out = subprocess.run(["gdb","-q","-nx","-batch","-x","dump_state.py",
        "--args","./cm_rb_easy", moves], capture_output=True, text=True).stdout
    for line in out.splitlines():
        if line.startswith("STATE:"): return line[len("STATE: "):]
random.seed(1337); ok = 0
for _ in range(12):
    mv = "".join(random.choice(ALPHA) for _ in range(random.randint(1,14)))
    mine, theirs = cube.run(mv).decode('latin1'), binary_state(mv)
    ok += (mine == theirs)
    print(f"[{'OK' if mine==theirs else 'XX'}] {mv:16s} mine={mine} bin={theirs}")
print(f"{ok}/12 matched")

[OK] lbBrrbLBuf       mine=BrjBboBjbbBrbvvrvoorojjv bin=BrjBboBjbbBrbvvrvoorojjv
[OK] BFubRfBDufuDl    mine=joBjbbjBrvBrvvrbrvbooBjo bin=joBjbbjBrvBrvvrbrvbooBjo
[OK] fBuubFfUBrDd     mine=bBBorjvrojrBBojrobbbvvvj bin=bBBorjvrojrBBojrobbbvvvj
[OK] LBfb             mine=BojobvjjovobjBrrrvvbBBrb bin=BojobvjjovobjBrrrvvbBBrb
[OK] drFRlDflrr       mine=BojrjbroojvBBrvjovBrbbbv bin=BojrjbroojvBBrvjovBrbbbv
[OK] UDufrUfUfRRDF    mine=BbboBovbjbjBvvBjvrrrjoro bin=BbboBovbjbjBvvBjvrrrjoro
[OK] dbrB             mine=ojbbrBrvrjovBojvbBrvobjB bin=ojbbrBrvrjovBojvbBrvobjB
[OK] r                mine=ojbbrbBBrorvjovvjBrvBbjo bin=ojbbrbBBrorvjovvjBrvBbjo
[OK] urRlUl           mine=rjvvbbjrBoBvoBvrBrjbjoob bin=rjvvbbjrBoBvoBvrBrjbjoob
[OK] fFRrLlllLfUb     mine=jooovoBjBBjvvrbbbvrrbjBr bin=jooovoBjBBjvvrbbbvrrbjBr
[OK] bbrdUldl         mine=orBbbjrrvjvbroBBvovjojBb bin=orBbbjrrvjvbroBBvovjojBb
[OK] fbBblrfFFDbLU    mine=jbbvorBBrorvbBvovBrjjjob bin=jbbvorBBrorvbBvovBrjjjob

12/12 matched

Byte-for-byte, every time. The dump_state.py helper is the same skeleton as the extractor, minus the identity injection:

# dump_state.py — gdb -q -nx -batch -x dump_state.py --args ./cm_rb_easy <MOVES>
import gdb
def base_addr():
    out = gdb.execute("info proc mappings", to_string=True)
    for line in out.splitlines():
        parts = line.split()
        if parts and parts[-1].endswith("cm_rb_easy"):
            return int(parts[0], 16)
gdb.execute("starti"); b = base_addr()
gdb.execute("break *0x%x" % (b + 0x1b27)); gdb.execute("continue")
inf = gdb.selected_inferior()
print("STATE:", bytes(inf.read_memory(b + 0x4048, 24)).decode('latin1'))
gdb.execute("kill")

Solving the scramble: what didn't work, then what did

For the worked example I wanted an actual flag — a move string the binary accepts — because recovering it end-to-end is the strongest possible proof the model is right. Since any uniform end-state counts, my first idea was a meet-in-the-middle: forward-BFS from the scramble, backward-BFS from every solved state, meet in the middle. But I don't know which colour sits on which face when solved, so I seeded the backward search with all 6! = 720 possible face→colour assignments (only 24 are legal cube orientations; the rest live in unreachable orbits and were meant to be harmless filler). That version (solve.py) expanded 720 sources to depth 7 and died silently — it exhausted memory before printing even the algebra header. Seeding 720 orbits' worth of frontier was simply too much state for the sandbox.

Second attempt: cut the backward search entirely and rely on the frontier growth being benign. A plain forward BFS from the scramble, checking is_solved on every dequeued node, stops at the first uniform state — which, by BFS, is a shortest solution. The gamble is that the author's scramble is shallow, so the search terminates long before the full state space is exhausted:

# solve2.py
from collections import deque
import cube
MOVES = "UDLRFBudlrfb"
start = bytes(cube.SCRAMBLE, 'latin1')
seen = {start: ""}; q = deque([start]); found = None; nodes = 0; maxdepth = 0
while q:
    s = q.popleft(); path = seen[s]
    if len(path) > maxdepth:
        maxdepth = len(path); print("depth", maxdepth, "nodes", nodes, flush=True)
    if cube.is_solved(s): found = path; break
    nodes += 1
    for m in MOVES:
        ns = cube.apply_move(s, m)
        if ns not in seen:
            seen[ns] = path + m; q.append(ns)
    if nodes > 6_000_000: print("cap hit", flush=True); break
print("FLAG:", repr(found), "len", len(found) if found else None, flush=True)
if found is not None:
    st = cube.run(found); print("verify:", st.decode('latin1'), "solved?", cube.is_solved(st))

$ python3 -u solve2.py
depth 1 nodes 1
depth 2 nodes 13
depth 3 nodes 127
depth 4 nodes 1051
depth 5 nodes 7590
depth 6 nodes 47118
depth 7 nodes 247044
depth 8 nodes 1053180
FLAG: 'ULLfULul' len 8
verify: oooojjjjBBBBrrrrvvvvbbbb solved? True

The scramble is eight quarter-turns from solved, and BFS found an optimal eight-move solution — ULLfULul — after touching ~1M states (a few seconds, well under the sandbox's memory ceiling). Note the branching: the frontier grows by roughly ×6–7 per level, so depth 8 was reachable but depth 12+ would not have been; the shallow scramble is what made the naïve search viable. The lesson from the failed MITM stands: the right move here was to shrink the search's fan-out, not add 720 sources to it.

And the binary agrees:

$ ./cm_rb_easy ULLfULul
[*] G00d flag!
$ ./cm_rb_easy ULLfULuU     # last move wrong
[!] Bad flag!

A worked example, byte by byte

Here is ULLfULul traced through the cube, one move per line, showing the full 24-byte state and the six faces. This is trace.py (for m in flag: st = cube.apply_move(st, m)), and it is exactly what the binary holds in .data:0x4048 at each step:

init : oobvbbjBrorvjBvrjBrvjBob   U=oobv B=bbjB F=rorv D=jBvr L=jBrv R=jBob
 U   : bovojBjBjBrvjBvrrorvbbob   U=bovo B=jBjB F=jBrv D=jBvr L=rorv R=bbob
 L   : BoBojvjjbBvvjBrrrrvobbob   U=BoBo B=jvjj F=bBvv D=jBrr L=rrvo R=bbob
 L   : jovojrjjBBBvbBvrvrorbbob   U=jovo B=jrjj F=BBBv D=bBvr L=vror R=bbob
 f   : jobojrjjBvBBrrvrvoovBbbb   U=jobo B=jrjj F=BvBB D=rrvr L=voov R=Bbbb
 U   : bjoovojjBbBBrrvrBvovjrbb   U=bjoo B=vojj F=BbBB D=rrvr L=Bvov R=jrbb
 L   : jjoovvjrbboBBrBroBvvjrbb   U=jjoo B=vvjr F=bboB D=BrBr L=oBvv R=jrbb
 u   : jojojrjroBoBBrBrvvvvbbbb   U=jojo B=jrjr F=oBoB D=BrBr L=vvvv R=bbbb
 l   : oooojjjjBBBBrrrrvvvvbbbb   U=oooo B=jjjj F=BBBB D=rrrr L=vvvv R=bbbb
solved? True

Walk the first move to see the machinery. init's F face is r o r v (bytes 8–11) and R face is j B o b (bytes 20–23). Applying P_U: new[8]=old[20]='j', new[9]=old[21]='B', so F becomes jBrv — R's top pair jB has slid onto F, exactly as the 0x132c handler's first four stores dictate. Meanwhile new[0..3]=old[2,0,3,1]='bovo', the U face's own 90° spin. Follow the diagonal down and each face collapses to one colour; after the final l every face is uniform and the check at 0x1e74 fires G00d flag!.

The solved colouring the binary lands on is a coherent cube — opposite faces are consistent — which is a nice sanity check that the scramble was a legal position all along:

face	solved colour
U	oooo — orange
B	jjjj — jaune (yellow)
F	BBBB — blanc (white)
D	rrrr — rouge (red)
L	vvvv — vert (green)
R	bbbb — bleu (blue)

The whole binary, re-implemented in prose

If you wanted to rebuild cm_rb_easy from scratch in any language, this is the complete specification:

1. Keep a 24-byte cube, six faces of four stickers, laid out U,B,F,D,L,R at byte offsets 0,4,8,12,16,20. Initialise it to the scramble oobvbbjBrorvjBvrjBrvjBob.
2. Require exactly one command-line argument; reject flags longer than 99 characters ([!] The flag is too long...).
3. Iterate over the flag's characters. For each character in {U,D,L,R,F,B} apply the corresponding quarter-turn permutation; for each in {u,d,l,r,f,b} apply the same permutation three times (the inverse). Ignore every other byte.
4. Each face turn is: rotate the turning face's four stickers by the cycle (0 2 3 1), and 4-cycle the two adjacent stickers on each of the four neighbouring faces (the twelve tables above give the exact wiring).
5. After the last character, print [*] G00d flag! iff all six faces are monochrome, else [!] Bad flag!.

There is no obfuscation beyond the stripped symbols and the switch-table indirection; the "trick," such as it is, is conceptual — recognising 24 bytes and a colour alphabet as a pocket cube, and realising the flag is a solving algorithm rather than a password. Once the cube is in view, the 12 permutations fall straight out of a gdb one-liner and the checker is a plain uniformity test.

Notes, honest limits

• The permutation tables were recovered empirically (identity injection under gdb) and then cross-validated against the hand-decoded U and the rot4/u disassembly. I read the U, u, and face-helper handlers instruction-by-instruction; the other five uppercase handlers I trusted to the differential test rather than transcribing all ~30 lines of each. The 12/12 byte-exact match over random 1–14-move strings is what backs those tables.
• ASLR could not be disabled in this sandbox, so all gdb work resolves the PIE base from /proc/pid/maps at runtime — hence one move per process in the extractor. It's slower but robust.
• The solver is a plain BFS, not a clever cube solver; it works only because the scramble is shallow (8 QTM). A deeper scramble would need the meet-in-the-middle done properly (seed the backward search from the 24 legal orientations, computed via whole-cube-rotation permutations, not from all 720 colourings).
• I did not consult any existing solution, comment thread, or writeup for this challenge; everything here comes from the binary, objdump, and gdb.

Artefacts

The download tarball contains the original cm_rb_easy (sha256 3e707363…c0d7) plus the scripts shown in full above: cube.py (the port), extract_one.py and dump_state.py (gdb helpers), difftest.py (the differential harness), solve2.py (the BFS solver), and trace.py (the worked example). Every one of them is inlined in this post; you can reproduce the entire analysis by copy-pasting.

References

• Tools: objdump (binutils), GNU gdb with its Python API, readelf for triage, ltrace, CPython 3.
• Target: crackmes.one — S01den's "cube" (Linux/x86-64 pocket-cube crackme, internal name cmRubiks).
• Background: this crackme uses lowercase letters for the inverse quarter-turn (u == U⁻¹), which is the author's private convention — standard Singmaster/WCA notation writes a counter-clockwise turn with a prime (U') and reserves lowercase letters for wide/double-layer turns. Also relevant: the 2×2×2 pocket cube's ~3.67M-position state space, quarter-turn diameter 14.