Evolving SBox: reversing 0xJam3z's 14 KB keyed hash, one Fisher-Yates shuffle at a time

A stripped 14 KB Linux ELF asks for a 31-character password and answers only "Nope." This is the full reconstruction of what it actually computes — a Fisher-Yates-shuffled S-box seeded from a magic constant, a 16-byte key schedule baked from the string NotThePasswordLol, and an eight-round splitmix-style keyed hash — plus a Python port whose output matches the binary bit-for-bit, validated under gdb.

The target

The challenge is Evolving SBox by 0xJam3z, posted to crackmes.one at difficulty 5.0, language C/C++, platform Unix/Linux. The description is terse: "Hint is in the challenge name!" The archive (password crackmes.one) yields a single executable named 0xJam3z-Medium.

$ file 0xJam3z-Medium
0xJam3z-Medium: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
  dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
  BuildID[sha1]=0f66b00fc268d7bdb85fc3d3f34b94c2062edd2f,
  for GNU/Linux 4.4.0, stripped
$ sha256sum 0xJam3z-Medium
c1e78f2a0ba7a15d9bf6a563f0874656437112b617b94d42cd858e3e477ef665
$ stat -c%s 0xJam3z-Medium
14440

rabin2 -I fills in the protections: a PIE with NX and a stack canary, partial RELRO, no symbols (stripped true, lsyms false), compiled with GCC 15.2.1 (a 2025 toolchain). The first 64 bytes are an unremarkable ELF header — nothing packed, nothing self-modifying:

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0300 3e00 0100 0000 9010 0000 0000 0000  ..>.............
00000020: 4000 0000 0000 0000 6831 0000 0000 0000  @.......h1......
00000030: 0000 0000 4000 3800 0e00 4000 1c00 1b00  [email protected]...@.....

Type 3 (ET_DYN, i.e. PIE), machine 0x3e (x86-64), entry at file offset 0x1090. No high-entropy blob, no UPX stub. This is plain compiled C that happens to be stripped — the "anti-RE" here is comprehension difficulty, not a packer.

First impressions

strings immediately leaks the whole UI plus one suspicious data string:

NotThePasswordLol
Reverse me and place the correct password here:
Correct! You solved the challenge.
Lucky guess?

rabin2 -z pins them in .rodata: NotThePasswordLol lives at vaddr 0x2008, the prompt at 0x2020, Nope. at 0x2054, Correct!... at 0x2060, and Lucky guess? at 0x2083. The imports (rabin2 -i) are minimal: puts, printf, fgets, strlen, strcspn, __stack_chk_fail. No scanf, no read, no crypto library — every byte of the algorithm is hand-rolled inside the binary.

A single ltrace run shows the I/O skeleton:

printf("Reverse me and place the correct"...)        = 48
fgets("AAAA...AAAA\n"..., 128, 0x7fa5f90268e0)        = 0x...41c0
strcspn("AAAA...AAAA\n"..., "\r\n")                   = 31
strlen("AAAA...AAAA")                                  = 31
puts("Nope.")                                          = 6

So: print prompt → fgets 128 bytes → strcspn(input, "\r\n") to find and chop the line ending → there's a length test (the input above is exactly 31 chars) → a strlen call (which, we'll see, belongs to a decoy) → verdict. Three distinct verdict strings exist — Correct!, Nope., Lucky guess? — which hints at more than a single yes/no branch. My initial hypothesis: the password is fixed-length, run through some keyed transform, and compared against a constant. The challenge name Evolving SBox suggests a substitution table that mutates. Let's confirm all of that statically.

I used radare2 5.x (r2 -A) and cross-read with Ghidra's decompiler. afl lists the functions; renaming them by role:

Address	Size	Role
0x15dc	809	main
0x1274	212	build_sbox — Fisher-Yates shuffle
0x1254	32	lcg — 64-bit PRNG step
0x1189	176	build_key — 16-byte key schedule
0x1348	402	evolving_hash — the real keyed hash
0x1239	27	rol8 — rotate-left-by-1
0x1543	153	decoy checksum (result unused)
0x14da	105	decoy hash (unreachable branch)

main, top to bottom

main allocates a 0x210-byte frame and immediately builds the S-box into a local buffer, then prompts and reads. From r2 -A -c 'pdf @ main':

; main @ 0x15dc — setup, build sbox, read line
0x15f6  lea  rax, [var_110h]       ; rax -> 256-byte sbox buffer
0x15fd  mov  rdi, rax
0x1600  call fcn.00001274          ; build_sbox(buf)
0x1605  lea  rax, str.Reverse_me...; the prompt
0x1614  call printf
0x1620  lea  rax, [s1]             ; 128-byte input buffer
0x1627  mov  esi, 0x80
0x162f  call fgets                 ; fgets(s1, 128, stdin)
0x1634  test rax, rax
0x1637  jne  0x1643                ; NULL -> bail out

After the read, strcspn(s1, "\r\n") returns the index of the first CR/LF; the code writes a NUL there to trim the newline, and stores that index as the effective length. The very next test is the length gate:

; main @ 0x1657 — trim newline, gate on length == 31
0x1657  call strcspn               ; len = strcspn(s1, "\r\n")
0x165c  mov  [var_1f8h], rax       ; save len
0x1674  mov  byte [rax+rdx], 0     ; s1[len] = 0
0x1677  cmp  qword [var_1f8h], 0x1f ; len == 31 ?
0x167f  je   0x169a                ; yes -> continue
0x1681  lea  rax, str.Nope.        ; no  -> "Nope." and exit
0x168b  call puts

So the password must be exactly 31 bytes. The code then copies those 31 bytes into a second buffer (var_1d0h) one byte at a time — a working copy the hash is allowed to clobber — via a loop running indices 0..0x1e:

; main @ 0x16a7 — copy s1[0..30] into var_1d0h (the working buffer)
0x16b8  movzx eax, byte [rax]      ; s1[i]
0x16ce  mov  byte [rax], cl        ; var_1d0h[i] = s1[i]
0x16d8  cmp  qword [var_200h], 0x1e
0x16e0  jbe  0x16a7                ; i <= 30

The length-gate tautology

Before the real check, main runs a stretch of arithmetic that looks like cryptography but is pure misdirection. It computes X = len ^ 0x1234, then evaluates (3*X) mod 7 two different ways and compares them:

; main @ 0x1705 — way #1: rcx = (3*(len^0x1234)) mod 7
0x170c  xor  rax, 0x1234
0x1718  add  rax, rax             ; 2X
0x171b  lea  rsi, [rax+rdx]       ; 3X
0x171f  movabs rdx, 0x2492492492492493 ; magic reciprocal of 7
0x172c  mul  rdx                  ; ... -> rcx = 3X mod 7
; main @ 0x1759 — way #2: same value, plus 7*(X&1)
0x1772  and  eax, 1
0x1775  neg  rax
0x1778  and  eax, 7              ; (-(X&1)) & 7  == 7 if X odd else 0
0x17af  cmp  rcx, rax            ; compare the two
0x17b2  jne  0x187a             ; mismatch -> decoy path

The constant 0x2492492492492493 is the well-known "divide by 7" reciprocal GCC emits for % 7. Way #2 adds (-(X&1)) & 7, which is 7 when X is odd and 0 when even. But 7 ≡ 0 (mod 7), so the addition can never change the residue. The two values are equal for every input length:

len=  0: branch1=1 branch2=1 equal=True
len= 30: branch1=6 branch2=6 equal=True
len= 31: branch1=2 branch2=2 equal=True
len=255: branch1=6 branch2=6 equal=True

The jne 0x187a is therefore never taken. Everything behind it — 0x187a onward, including the Lucky guess? string and a second hash with the magic 0xdeadbeefcafebabe — is dead code, a red herring planted to waste an analyst's time. The control flow really only ever has two destinations:

The real check

Past the tautology, main calls the hash on the 31-byte working buffer and compares the 64-bit result to a single embedded constant:

; main @ 0x17b8 — the only check that matters
0x17ce  call fcn.00001348          ; h = evolving_hash(buf, 31, sbox)
0x17d3  mov  [var_1e8h], rax
0x1834  movabs rax, 0xe2f2b4005fbf9874 ; the target
0x184c  cmp  rax, [var_1d8h]       ; h == 0xe2f2b4005fbf9874 ?
0x1853  jne  0x1869               ; no -> "Nope."
0x1855  lea  rax, str.Correct__You_solved...
0x185f  call puts                 ; "Correct! You solved the challenge."

There is a second call fcn.00001348 at 0x1828 on a fresh copy of the (now-mutated) buffer, but its result lands in var_1e0h and is never read — another decoy. The verdict reduces to a single equation:

evolving_hash(password, 31, sbox) == 0xe2f2b4005fbf9874

Everything interesting is in fcn.00001274 (the S-box) and fcn.00001348 (the hash). Let's reverse them.

The seed: building the evolving S-box

fcn.00001274 takes a pointer to a 256-byte buffer and fills it. It opens with an identity initialization — buf[i] = i for i = 0..255:

; fcn.00001274 @ 0x1289 — identity fill
0x1289  mov  eax, [var_18h]        ; i
0x1293  add  rax, rdx              ; &buf[i]
0x1299  mov  byte [rax], dl        ; buf[i] = i (low byte)
0x129b  add  dword [var_18h], 1
0x12a6  jle  0x1289                ; i <= 0xff

Then it seeds a 64-bit state with 0xc0de1234abcdef01 and runs a Fisher-Yates shuffle from i = 255 down to 1, advancing a PRNG each step and using the high 32 bits modulo (i+1) to pick the swap partner:

; fcn.00001274 @ 0x12a8 — Fisher-Yates with PRNG
0x12a8  movabs rax, 0xc0de1234abcdef01 ; the SEED
0x12b6  mov  dword [var_14h], 0xff     ; i = 255
0x12c6  call fcn.00001254              ; state = lcg(state)
0x12d3  shr  rax, 0x20                 ; high 32 bits
0x12ea  div  ecx                       ; (high32) % (i+1)  -> edx = j
0x1311  ...  swap buf[i], buf[j]
0x1336  sub  dword [var_14h], 1
0x133e  jg   0x12bf                     ; i > 0

The PRNG fcn.00001254 is a textbook 64-bit linear congruential generator using Knuth's MMIX multiplier:

; fcn.00001254 — state = state*0x5851f42d4c957f2d + 1
0x1260  movabs rdx, 0x5851f42d4c957f2d
0x126a  imul rax, rdx
0x126e  add  rax, 1

Because the seed and multiplier are constants, the S-box is completely fixed — it does not depend on the password at all. The "evolving" in the title refers to how the identity table evolves into a permutation under the shuffle (and, as we'll see, the hash's running state evolves through it). Re-running the exact shuffle in Python and dumping memory under gdb agree byte-for-byte. Here is the full 256-entry S-box (python3 -c 'from evolvingsbox import build_sbox; ...'), confirmed a valid permutation (isperm: True, byte-sum 32640):

     x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xa xb xc xd xe xf
0x   13 6e ea 15 f3 79 8b 74 2c 3b ac 85 20 eb 90 32
1x   4e e8 dc 11 09 82 b7 d5 6c 0b 7e 33 51 0e 1e 83
2x   02 f1 62 2a 5f ba e0 a8 41 99 2f 34 64 4a c1 a2
3x   fa 88 cb a5 87 e4 97 47 94 3c 8f 57 8c 9e 12 2e
4x   10 91 54 e9 6d bd 0f 61 f2 14 a6 d6 de 66 01 ef
5x   f8 d3 ee 52 df 1a c7 1c 24 b6 a4 d8 7f d0 6f 2d
6x   d2 22 25 89 cc 68 ce 80 27 18 23 39 08 7d 5c 5a
7x   84 ae 6a e5 1b 9c db fc bf 5d 05 93 9a 77 c0 21
8x   ed 35 00 1d b2 3f dd 6b 9f a7 a1 ec 70 b4 72 b5
9x   c2 b1 f4 43 40 73 a0 0a 71 d7 58 30 ad 60 04 03
ax   ca ff c4 c5 63 0d f6 26 98 86 fe c9 9d e3 48 75
bx   8d b3 b8 4f af f5 da 92 c3 aa e6 3d fb 36 56 a3
cx   f7 bc 46 78 44 a9 07 d1 1f 8e be 4c 53 e2 cf 9b
dx   16 65 c8 17 37 e7 06 f0 69 76 b0 0c d4 42 31 96
ex   7c f9 cd c6 b9 38 3a 49 7b 95 2b 19 45 5e 55 4d
fx   fd 5b e1 81 29 50 bb 4b 8a d9 3e ab 59 28 67 7a

So sbox[0x00] = 0x13, sbox[0xd3] = 0x17, sbox[0xff] = 0x7a. Memorize sbox[0xd3] = 0x17; it shows up in the worked example.

The key schedule

fcn.00001348 begins by calling fcn.00001189, which fills a 16-byte key from the constant string NotThePasswordLol (this is the only use of that string — it is not the password). The recurrence is a djb2-flavoured rolling hash, h = 33*h + src[c] + c, emitting one byte per step:

; fcn.00001189 @ 0x11a9 — key[c] = (33*h + src[c] + c) & 0xff
0x11af  shl  eax, 5               ; 32*h
0x11b2  lea  ecx, [rax+rdx]       ; 33*h
0x11c2  movzx eax, byte [rax]     ; src[c]
0x11c5  lea  edx, [rcx+rax]       ; 33*h + src[c]
0x11cb  add  eax, edx             ; + c
0x11cd  mov  byte [var_dh], al    ; h = result (byte)
0x11e1  mov  byte [rdx+rax], al   ; key[c] = h
0x11ff  jle  0x11a9               ; c <= 15

Seeded with h = 0x42 ('B') and walking the 16 bytes NotThePasswordLo (the 17th char l is never reached because the index cap c <= 0xf fires first), the key resolves to a fixed 16 bytes (build_key()):

key = d0 40 b6 cd d9 63 19 a1 3c 38 b9 53 31 c2 5c 5a

gdb confirms this exact array sits in the hash's stack frame at runtime. Like the S-box, the key is constant.

The hash

fcn.00001348(data, len, sbox) is the heart. After building the key, it sets up four pieces of state:

• acc8 — an 8-bit accumulator, initialized to 0x42 ('B') at 0x1377.
• rounds = 8 (0x137b).
• h — the 64-bit output, initialized to 0x008f3a9c4d2b1e07 (0x1382).
• two nested loops: outer r = 0..7, inner i = 0..len-1.

Inside the inner loop, each byte is whitened, substituted, rotated, and offset. First the whitening — three XORs against the key (indexed by (i+r) mod 16), the accumulator, and the index itself:

; fcn.00001348 @ 0x13a9 — c = data[i]; whiten
0x13b4  movzx eax, byte [rax]      ; c = data[i]
0x13c7  and  eax, 0xf              ; (i + r) & 0xf
0x13ca  movzx eax, byte [rbp+rax-0x20] ; key[(i+r)&0xf]
0x13cf  xor  byte [var_39h], al    ; c ^= key[...]
0x13d6  xor  byte [var_39h], al    ; c ^= acc8
0x13d9  xor  byte [var_39h], al    ; c ^= (i & 0xff)

Then substitution through the S-box, a rotate-left-by-1, and an index-dependent additive offset:

; fcn.00001348 @ 0x13e0 — substitute, rotate, offset
0x13eb  movzx eax, byte [rax]      ; c = sbox[c]
0x13f7  call fcn.00001239          ; c = rol8(c, 1)
; compute 7*i + 13*r  (0x13ff..0x141c), then:
0x141e  add  byte [var_39h], al    ; c += (7*i + 13*r) & 0xff

The rotate fcn.00001239 is a one-byte ROL-by-1: (2*x | (x>>7)) & 0xff.

; fcn.00001239 — rol8(x, 1)
0x1246  lea  edx, [rax+rax]        ; 2x
0x124d  shr  al, 7                 ; x >> 7
0x1250  or   eax, edx              ; (2x | top bit)

Next the accumulator update — a two-step recurrence that folds in the freshly-transformed byte and the round number, then runs its own 33*acc8 + 17 LCG-mod-256 mixing:

; fcn.00001348 @ 0x1421 — acc8 update
0x1425  add  edx, eax             ; acc8 + c
0x142e  add  eax, edx             ; + r
0x1430  mov  byte [var_3ah], al   ; acc8 = (acc8 + c + r) & 0xff
0x1439  shl  eax, 5               ; 32*acc8
0x143c  add  eax, edx             ; 33*acc8
0x143e  add  eax, 0x11            ; + 17
0x1441  mov  byte [var_3ah], al   ; acc8 = (33*acc8 + 17) & 0xff

The transformed byte is then written back into data[i] — this is the in-place mutation that makes round r operate on round r-1's output — and finally mixed into the 64-bit h via a shifted XOR followed by a splitmix64-style multiply-add:

; fcn.00001348 @ 0x1444 — store back, fold into h
0x1453  mov  byte [rdx], al        ; data[i] = c
0x146b  and  eax, 0x3f             ; shift = (i + 5*r) & 0x3f
0x1470  shl  rsi, cl               ; c << shift  (64-bit)
0x1476  xor  [var_30h], rax        ; h ^= (c << shift)
0x1488  imul rax, 0x9e3779b97f4a7c15 ; h *= golden-ratio odd mult
0x1496  add  rax, 0xbf58476d1ce4e5b9 ; h += splitmix increment
0x1499  mov  [var_30h], rax        ; store h

Those last two constants — 0x9e3779b97f4a7c15 and 0xbf58476d1ce4e5b9 — are borrowed from Sebastiano Vigna's splitmix64 generator, but with their roles swapped: in canonical splitmix64 0x9e3779b97f4a7c15 is the additive increment and 0xbf58476d1ce4e5b9 a mix multiplier, whereas here 0x9e37... multiplies and 0xbf58... is added. So this step is really a golden-ratio-multiplier Lehmer/LCG step reusing splitmix's constants rather than the splitmix64 mixer itself. Multiplying by an odd constant and adding makes the step a bijection on 64-bit state, so given the sequence of c << shift values you could in principle run h backwards — but only if you knew every c, which depends on the password. We'll return to that.

Constants and data tables

Everything the algorithm needs, in one place (all read directly out of the disassembly at the cited offsets):

Constant	Value	Where	Meaning
S-box seed	0xc0de1234abcdef01	0x12a8	Fisher-Yates PRNG seed
LCG multiplier	0x5851f42d4c957f2d	0x1260	MMIX/PCG step
key source	"NotThePasswordLol"	0x2008	first 16 bytes feed the schedule
key seed	0x42	0x119c	djb2-style start
acc8 seed	0x42	0x1377	accumulator start
h seed	0x008f3a9c4d2b1e07	0x1382	64-bit state start
rounds	8	0x137b	outer loop count
length	31 (0x1f)	0x1677	required password length
splitmix mult	0x9e3779b97f4a7c15	0x147e	h mixing
splitmix add	0xbf58476d1ce4e5b9	0x148c	h mixing
target	0xe2f2b4005fbf9874	0x1834	the Correct! constant
acc8 mixing	33*acc8 + 17	0x1439	per-byte
byte offset	7*i + 13*r	0x13ff	per-byte additive
shift	(i + 5*r) & 0x3f	0x1465	h ^= shift
decoy target #1	0xdeadbeefcafebabe	0x18b7	unreachable Lucky guess?
decoy target #2	0xe2f2b4005fbf9874 cmp dead	0x1828	second hash, result unused

The per-byte transformation, written as one expression (with acc8 the running accumulator):

c  = data[i]
c  = sbox[ c ^ key[(i+r)&15] ^ acc8 ^ (i&255) ]
c  = ((c << 1) | (c >> 7)) & 255
c  = (c + 7*i + 13*r) & 255
acc8 = (33*((acc8 + c + r) & 255) + 17) & 255
h  = ((h ^ (c << ((i + 5*r) & 63))) * 0x9e3779b97f4a7c15 + 0xbf58476d1ce4e5b9) mod 2^64
data[i] = c

A worked example

Let's trace the first inner step for input "A"*31 (so data[i] = 0x41), round r = 0, index i = 0, with acc8 = 0x42 and h = 0x008f3a9c4d2b1e07:

1. c = data[0] = 0x41.
2. c ^= key[(0+0)&15] = key[0] = 0xd0 → 0x41 ^ 0xd0 = 0x91.
3. c ^= acc8 = 0x42 → 0x91 ^ 0x42 = 0xd3.
4. c ^= (0 & 255) = 0 → 0xd3.
5. c = sbox[0xd3] = 0x17 (row dx, column 3 of the table above).
6. c = rol8(0x17) = 0x2e (top bit clear, so just 0x17 << 1).
7. c += 7*0 + 13*0 = 0 → c = 0x2e.
8. acc8 = (0x42 + 0x2e + 0) & 255 = 0x70; then acc8 = (33*0x70 + 17) & 255 = 0xe81 & 255 = 0x81.
9. data[0] = 0x2e.
10. shift = (0 + 0) & 63 = 0; h ^= 0x2e << 0 → h = 0x008f3a9c4d2b1e29; then h = (h * 0x9e3779b97f4a7c15 + 0xbf58476d1ce4e5b9) mod 2^64 = 0x952baaae62e43b16.

The instrumented Python (trace=True) prints exactly this, and the next three steps:

  r=0 i=0 c=0x2e acc8=0x81 shift= 0 h=0x952baaae62e43b16
  r=0 i=1 c=0x71 acc8=0x43 shift= 1 h=0xccc336ad273000bd
  r=0 i=2 c=0xc3 acc8=0xd7 shift= 2 h=0xdace1c3b75c8ef3e
  r=0 i=3 c=0x5d acc8=0xc5 shift= 3 h=0x7424251303701047

Carry all 8×31 = 248 steps through and "A"*31 hashes to 0x847944866fbcba0b. After eight rounds the working buffer — which started as 31 0x41 bytes — has been ground into:

13 ae df 53 18 ac 0c 65 2a e1 e7 21 82 1a 8b 50
4c 17 ce e1 d9 35 8e 7f 3f 0b ba 51 23 36 09

Python re-implementation

This is the complete port (evolvingsbox.py). It references nothing from the binary at runtime — it rebuilds the S-box, the key, and the hash from the constants recovered above.

#!/usr/bin/env python3
"""Faithful re-implementation of 0xJam3z 'Evolving SBox' (crackmes.one)."""

M64 = (1 << 64) - 1

# --- fcn.00001254 : 64-bit LCG step (MMIX / Knuth multiplier) -----------
def lcg(state):
    return (state * 0x5851F42D4C957F2D + 1) & M64

# --- fcn.00001274 : Fisher-Yates shuffle of identity, seeded ------------
SBOX_SEED = 0xC0DE1234ABCDEF01
def build_sbox():
    box = list(range(256))
    state = SBOX_SEED
    for i in range(255, 0, -1):       # i = 255 .. 1
        state = lcg(state)
        j = (state >> 32) % (i + 1)   # high 32 bits modulo (i+1)
        box[i], box[j] = box[j], box[i]
    return box

# --- fcn.00001189 : 16-byte key schedule from a fixed string ------------
KEY_SRC = b"NotThePasswordLol"
def build_key():
    key = []
    h = 0x42                           # 'B'
    for c in range(16):
        h = (33 * h + KEY_SRC[c] + c) & 0xFF
        key.append(h)
    return key

# --- fcn.00001239 : rotate-left-by-1 on a byte --------------------------
def rol8(x):
    x &= 0xFF
    return ((x << 1) | (x >> 7)) & 0xFF

# --- fcn.00001348 : the keyed hash (8 rounds, in-place mutation) ---------
H0   = 0x008F3A9C4D2B1E07
MULT = 0x9E3779B97F4A7C15
ADD  = 0xBF58476D1CE4E5B9
ACC0 = 0x42
ROUNDS = 8

def evolving_hash(data, sbox=None, key=None):
    if sbox is None: sbox = build_sbox()
    if key  is None: key  = build_key()
    data = bytearray(data)             # mutated in place, like the binary
    acc8 = ACC0
    h    = H0
    n    = len(data)
    for r in range(ROUNDS):
        for i in range(n):
            c  = data[i]
            c ^= key[(i + r) & 0xF]
            c ^= acc8
            c ^= (i & 0xFF)
            c  = sbox[c]
            c  = rol8(c)
            c  = (c + 7 * i + 13 * r) & 0xFF
            acc8 = (acc8 + c + r) & 0xFF
            acc8 = (33 * acc8 + 17) & 0xFF
            data[i] = c
            shift = (i + 5 * r) & 0x3F
            h ^= (c << shift) & M64
            h  = (h * MULT + ADD) & M64
    return h

TARGET = 0xE2F2B4005FBF9874

if __name__ == "__main__":
    import sys
    pw = (sys.argv[1].encode() if len(sys.argv) > 1 else b"A"*31)[:31].ljust(31, b"A")
    h = evolving_hash(pw)
    print(f"hash = 0x{h:016x}  match={h == TARGET}")

Ground truth: validating against the binary

A re-implementation is only worth the validation behind it. The binary never prints its hash, so I extracted it under gdb 14 by computing the PIE base from AT_ENTRY in the auxiliary vector (ASLR couldn't be disabled in the sandbox), then breakpointing right after the first evolving_hash returns at file offset 0x17d3 and reading RAX. Snippet of the gdb driver:

starti < /tmp/in.txt
# AT_ENTRY - 0x1090 == PIE base
break *($base + 0x17ce)   # before hash: rdx=sbox, rdi=pwbuf
break *($base + 0x17d3)   # after hash:  rax=result

For "A"*31 the breakpoint at 0x17ce shows the in-memory S-box matching my table, and the breakpoint at 0x17d3 shows the hash:

SBOX[0:16] from mem: 13 6e ea 15 f3 79 8b 74 2c 3b ac 85 20 eb 90 32
after 1st hash RAX = 0x847944866fbcba0b
mutated buf:         13 ae df 53 18 ac 0c 65 2a e1 e7 21 82 1a 8b 50
                     4c 17 ce e1 d9 35 8e 7f 3f 0b ba 51 23 36 09

The S-box bytes, the final hash, and the in-place-mutated buffer all match my Python exactly. Three inputs, three matches:

input	binary RAX	Python evolving_hash
"A"*31	0x847944866fbcba0b	0x847944866fbcba0b
crackmes.one_evolving_sbox_2025	0xebe067e84a1a3e03	0xebe067e84a1a3e03
0123456789abcdefghijklmnopqrstu	0x717ed95b92842809	0x717ed95b92842809

That's the proof the reconstruction is faithful: for any 31-byte input, the Python and the ELF compute the identical 64-bit value.

Can we recover the password?

The challenge framing invites you to "extract the flag," but as a reverse-me the honest answer about the password itself is worth stating plainly. The check is evolving_hash(pw, 31) == 0xe2f2b4005fbf9874 — a map from 248 input bits (31 bytes) down to a 64-bit output. It is a compressing, one-way function. The splitmix multiply-add is individually invertible, but to walk h backwards you need the full sequence of transformed bytes c, and those are exactly what depend on the unknown password; the acc8 chain couples every byte to every earlier byte across all eight rounds, so there's no per-byte separation to exploit. Brute-forcing a 64-bit target by forward evaluation is ~2⁶⁴ work.

I did try the cheap thing first — a handful of thematically plausible 31-char guesses — and documented the misses:

b'EvolvingSBoxEvolvingSBoxEvolvin' -> 0xbb38978944e17e76
b'0xJam3z_EvolvingSBox_Crackme!!!' -> 0xc574cf5604217496
b'NotThePasswordLolNotThePassword' -> 0xf4f7c778a040ebab
b'EvolvingSBox_is_the_password_!!' -> 0x64bc9e14b0951705

None hit 0xe2f2b4005fbf9874. That's expected: the construction is designed so that modeling it (which we've done, exactly) is the achievable goal, while inverting it is not. Note also that the check would accept any 31-byte preimage of the target, not a unique string — so "the password" isn't even unique. For this kind of lab, the deliverable is the validated model, and we have it.

The decoys

Two functions exist purely to burn analyst time, and naming them is part of the writeup:

• fcn.00001543 is a character-class checksum over the raw input: +3 for A–Z, +2 for a–z, +1 for 0–9, +4 otherwise, finishing with (7*len) ^ sum (0x15ca: 8*len - len, then xor). main stores its result at var_20ch and never reads it again. The strlen we saw in ltrace belongs here.
• fcn.000014da is a second 64-bit hash (state = 0x123456789abcdef0; per byte state += data[i]*((i+1)&0xff), then state ^= ror64(state,13)), compared against 0xdeadbeefcafebabe to print Lucky guess?. It sits entirely behind the jne 0x187a we proved is never taken — unreachable for any 31-byte input.

Recognizing these as dead weight is most of the difficulty rating. The live path is small once you see it; the binary's defense is making you prove that the scary-looking arithmetic and the second hash don't matter.

What the binary is, in one sentence

Evolving SBox is a hand-rolled keyed hash: a fixed Fisher-Yates S-box (seed 0xc0de1234abcdef01), a fixed 16-byte key derived from NotThePasswordLol, and an 8-round substitution-permutation over the 31-byte input where each byte is whitened, S-boxed, rotated, offset, and folded — with feedback — into a splitmix64-mixed 64-bit accumulator that must equal 0xe2f2b4005fbf9874. The "evolving" is real: the input buffer is overwritten every round, and the accumulator state chains every position to every other. The whole thing is reproducible in ~50 lines of Python, and that Python matches the binary bit-for-bit.

References & artefacts

• Target: Evolving SBox by 0xJam3z, crackmes.one (difficulty 5.0, Linux x86-64). Binary SHA-256 c1e78f2a0ba7a15d9bf6a563f0874656437112b617b94d42cd858e3e477ef665.
• Tools: radare2 5.x (-A, pdf), GNU gdb 14 (auxv-relative breakpoints under PIE), ltrace, rabin2, xxd, Python 3.
• Background reading (general, not solution): Sebastiano Vigna's splitmix64 (0x9e3779b97f4a7c15 / 0xbf58476d1ce4e5b9); Knuth's MMIX LCG multiplier 0x5851f42d4c957f2d; Fisher–Yates shuffle.
• Artefacts in the download tarball: the ELF (evolvingsbox), evolvingsbox.py (the port), verify.py and explore.py (the validations above), and gt.gdb (the ground-truth extractor).