IDEHv7 CTF Writeups

IDEH is a Moroccan CTF competition hosted by INPT. During this event, I solved many challenges while playing solo lmao, and it was an amazing experience overall. The competition was intense, fun, and full of learning opportunities. I also had the chance to meet and connect with many great people from the community big thanks to the organizers and especially to the challenge authors Have fun reading, and see you next year.

📎 Attachments

exfil.apk

IDEH CTF — Exfil (Android Reverse Engineering)

Category: Mobile / Reverse Engineering

Flag format: IDEH{…}

1) Challenge Overview

We are given an Android APK named exfil.apk. The goal is to analyze the application and recover a hidden secret stored inside it.

Initial assumption: The application hides sensitive data and exposes some functionality through a WebView JavaScript bridge.

Step 1 — Static analysis

First, decompile the APK.

1
jadx exfil.apk -d out

This gives us:

1
out/
2
 ├── resources/
3
 └── sources/

Searching for JavaScript bridges:

1
grep -R "JavascriptInterface" -n out/sources

Output:

1
sources/com/cit/ideh/exfil/DocsActivity.java
2
sources/i1/a.java

The interesting class is:

1
sources/i1/a.java

This file is injected into a WebView as the JavaScript object IDEH.

Step 2 — Inspecting the exposed interface

Opening sources/i1/a.java:

1
nano sources/i1/a.java

We find:

1
@JavascriptInterface
2
public final String readVault() {
3
    try {
4
        return a();
5
    } catch (Exception unused) {
6
        return "error";
7
    }
8
}

And the real logic is inside function a().

Step 3 — Understanding the crypto

The method a() does the following:

1. Loads encrypted blob

1
InputStream is = getResources().openRawResource(R.raw.flag_blob);

This corresponds to:

1
resources/res/raw/flag_blob

2. Splits the blob

1
nonce = blob[0..11]
2
ciphertext = blob[12..]

So the file is:

1
[ 12 bytes nonce | encrypted data + GCM tag ]

3. Builds AES key from APK signature

1
Signature sig = packageManager.getPackageInfo(...).signingInfo.getApkContentsSigners()[0];
2
byte[] digest = SHA256(sig.toByteArray());
3
SecretKeySpec key = new SecretKeySpec(digest[0:16], "AES");

So:

1
AES key = first 16 bytes of SHA256(apk signing certificate)

4. Uses package name as AAD

1
cipher.updateAAD("com.cit.ideh.exfil".getBytes());

So the authenticated data is:

1
AAD = "com.cit.ideh.exfil"

5. Decrypts using AES-GCM

1
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
2
cipher.init(DECRYPT, key, new GCMParameterSpec(128, nonce));
3
plaintext = cipher.doFinal(ciphertext);

The output is directly returned as a string.

Step 4 — Extracting the flag

To decrypt, we need:

After reproducing this logic and decrypting the blob, we obtain:

IDEH{m4ster_0f_4ndro1d}

IDEH CTF — Frozen Truth

📎 Attachments

frozen_truth

Category: Reverse Engineering

Format: IDEH{…}

1) Executive Summary

The challenge provides a Linux binary named frozen_truth acting as a flag checker. Initial execution fails due to a GLIBC version mismatch, which strongly suggests that static reverse engineering is required.

By identifying the binary as a PyInstaller-packed Python 3.8 executable, extracting its contents, and reversing the embedded challenge.pyc, we recover a simple Caesar-style decoding routine with a constant shift.

This leads directly to the final flag.

Step 1 — File Identification

1
file frozen_truth

Output:

1
frozen_truth: ELF 64-bit LSB executable, x86-64, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0

Trying to execute it:

1
./frozen_truth

Result:

1
libpython3.8.so.1.0: version `GLIBC_2.38' not found

So instead of running it, we move to static analysis.

Running strings reveals:

1
PYZ-00.pyz
2
pyi-runtime-tmpdir
3
pyiboot01_bootstrap
4
libpython3.8.so
5
_MEIPASS

This is a classic PyInstaller executable.

Step 2 — Extracting the PyInstaller Archive

We use pyinstxtractor-ng:

1
python3 -m pip install --user pyinstxtractor-ng
2
pyinstxtractor-ng frozen_truth

This creates:

1
frozen_truth_extracted/

Listing files:

1
challenge.pyc
2
PYZ.pyz
3
PYZ.pyz_extracted/
4
libpython3.8.so.1.0
5
...

The file of interest is clearly:

1
challenge.pyc

Step 3 — Decompiling the Python Bytecode

We use uncompyle6:

1
python3 -m pip install --user uncompyle6
2
uncompyle6 challenge.pyc

Recovered Python source (simplified):

1
SHIFT = 3
2

3
encoded_flag = b'...'
4

5
def decode(data):
6
    return bytes([(b - SHIFT) % 256 for b in data])
7

8
def main():
9
    user = input("Enter flag: ").encode()
10
    if user == decode(encoded_flag):
11
        print("Correct!")
12
    else:
13
        print("Wrong!")
14

15
if __name__ == "__main__":
16
    main()

Key observations:

The flag is not dynamically computed

It is stored as encoded_flag

Each byte is decoded with:

1
decoded_byte = encoded_byte - 3

Simple Caesar shift on raw bytes.

Step 4 — Recovering the Flag

We dump encoded_flag and decode it:

1
encoded = b"..."
2
print(bytes([(b - 3) % 256 for b in encoded]))

Output:

IDEH{compiling_wi7h_pyins7all3r_is_no7_s3cur3}

IDEH CTF – Insecured IoT Device

📎 Attachments

router_dump.bin

Category: Forensics

Flag format: IDEH{}

Executive Summary

In this challenge, we are given a raw binary dump extracted from an insecure IoT device. The goal is to analyze the firmware, extract its filesystem, locate suspicious components, and recover a hidden flag.

By carving the firmware image, mounting the embedded filesystem, and analyzing internal scripts and data files, we discover that the flag is split across several locations and encoded in Base64. After decoding and reassembling these parts, we recover the final flag.

1) Provided File

1
router_dump.bin

This appears to be a full flash dump / firmware image from an IoT router-like device.

Step 1 – Initial Recon

First, identify the file:

1
file router_dump.bin

output :

1
router_dump.bin: data

No clear format, so next step is firmware carving.

Step 2 – Firmware Analysis with binwalk

We scan the dump to locate embedded filesystems and compressed sections.

1
binwalk -e router_dump.bin

Result shows something similar to:

1
DECIMAL       HEXADECIMAL     DESCRIPTION
2
------------------------------------------------
3
65536         0x10000         Squashfs filesystem, little endian

Binwalk automatically extracts it into:

1
_extracted/
2
└── squashfs-root/

Step 3 – Exploring the Filesystem

Navigate into the extracted filesystem:

1
cd _extracted/squashfs-root
2
ls

Typical embedded Linux layout:

1
bin/  etc/  lib/  usr/  var/  sbin/  tmp/

This confirms the presence of a full Linux-based IoT firmware.

Step 4 – Hunting for Interesting Files

We search for scripts, configs, or suspicious data:

1
find . -type f | grep -i "telemetry\|state\|device\|flag"

Interesting files discovered:

1
./etc/device.id
2
./bin/print
3
./var/lib/telemetry/state.cache

Step 5 – Static Analysis of Files

1️⃣ /etc/device.id

1
cat etc/device.id

Output:

1
SURFSGtjMDBs

Decode:

1
echo SURFSGtjMDBs | base64 -d

Result:

1
IDEH{c00l

2️⃣ /bin/print

Checking the file:

1
strings bin/print

We find an embedded Base64 string:

1
X2Yxcm13NHJl

Decode:

1
echo X2Yxcm13NHJl | base64 -d

Result:

1
_f1rmw4re

3️⃣ /var/lib/telemetry/state.cache

1
cat var/lib/telemetry/state.cache

Output:

1
X2FuNGx5czFzfQ==

Decode:

1
echo X2FuNGx5czFzfQ== | base64 -d

Result:

1
_an4lys1s}

Step 6 – Rebuilding the Flag

Collected parts:

1
IDEH{c00l
2
_f1rmw4re
3
_an4lys1s}

Final flag:

IDEH{c00l_f1rmw4re_an4lys1s}

IDEH Rev — “This is the end.”

📎 Attachments

chall

Category: Reverse Engineering

Flag format: IDEH{…}

1) Executive Summary

The binary prompts for input, enforces a strict length of 26, then runs a small stack-based virtual machine over a bytecode program stored in .rodata. The VM computes a sum of 26 byte-sized checks of the form:

1
             (bi​⊕bi+1​)⊕ci​​

and succeeds only if the sum is 0, which (because the sum can’t overflow 32-bit) forces every term to be 0, giving direct XOR constraints between consecutive characters. Using the known flag prefix IDEH{ resolves the full flag.

2) Basic Recon

1
file chall
2
# chall: ELF 64-bit LSB executable, x86-64, statically linked, stripped

3) Locating main via String Xrefs

The prompt string “oui?” lives in .rodata. We locate it and then find its xref in .text.

Using offsets (from readelf -S):

.rodata vaddr: 0x47f000

.rodata file offset: 0x7f000

The prompt is at vaddr 0x47f010, and in the disassembly we find:

1
401825: lea rdi, [rip+0x7d7e4]  # 0x47f010 -> "oui?"
2
401849: call puts
3
40185d: call fgets
4
...
5
401887: cmp rax, 0x1a          # length check == 26
6
40189c: call 0x401a30          # VM validator(program, size, input)
7
4018a5: je  success
8
4018a7: lea rdi, "non..."
9
4018ae: call puts

So the flow is:

Print prompt “oui?”

Read input (up to 0x100 bytes)

Strip newline

Enforce length == 26

Run validator sub_401a30(program_ptr, program_len, input)

If validator returns 0 → success message, else failure

4) Understanding the Validator VM (0x401a30)

4.1 Bytecode location

The VM is called with:

rdi = 0x4849a0 (bytecode program)

esi = 0x1d9 (program size = 473 bytes)

rdx = input

So the bytecode begins at .rodata:0x4849a0.

4.2 Instruction set

The VM is a stack machine holding 32-bit integers in a local array.

It dispatches on opcode 0..5 via a jump table. The table resolves to handlers:

Important detail: this VM uses variable-length instructions:

PUSH_* = 1 opcode byte + 4 imm bytes (total 5)

arithmetic ops = opcode only (total 1)

5) Decompiling the Bytecode Program Logic

When decoding the bytecode, we see:

PUSH_INPUT appears 52 times

XOR appears 52 times

ADD appears 26 times

PUSH_CONST appears 27 times

This strongly suggests 26 independent checks being summed.

Reconstructing the stack expression reveals the VM computes:

and success requires result == 0.

5.1 Why this becomes 26 independent constraints

So the sum is at most:

26×255=6630

No 32-bit overflow can occur, so:

Thus for each i:

6) Extracted Constants

From the bytecode, the constants are:

1
c[0..25] =
2
[13, 1, 13, 51, 50, 22, 55, 91, 112, 40, 2, 7, 49, 19, 124, 95, 0, 32, 57, 69, 108, 9, 27, 120, 72, 52]

So:

b1 = b0 XOR 13

b2 = b1 XOR 1

…

b25 = b24 XOR 72

and finally the cycle condition matches automatically (b25 XOR b0 == 52)

This means the whole string is determined by b0.

7) Recovering the Flag

We know the required format begins with IDEH{, so:

b0 = ‘I’

Generate the chain:

1
b[0] = 'I'
2
b[i+1] = b[i] ^ c[i]

8) Solver Script (Extracts from the Binary)

This script:

extracts the program bytes from .rodata at 0x4849a0

decodes the VM bytecode (variable-length)

reconstructs the c[i] constants

rebuilds the flag using b0=‘I’

1
#!/usr/bin/env python3
2
from pathlib import Path
3

4
BIN = "chall"
5

6
RO_VA  = 0x47F000
7
RO_OFF = 0x7F000
8

9
PROG_VA   = 0x4849A0
10
PROG_SIZE = 0x1D9
11

12
def va_to_off(va):
13
    return RO_OFF + (va - RO_VA)
14

15
def decode_vm(prog, size):
16
    pc = 0
17
    ins = []
18
    while pc < size:
19
        op = prog[pc]
20
        if op in (0, 5):
21
            imm = int.from_bytes(prog[pc+1:pc+5], "little")
22
            ins.append((pc, op, imm))
23
            pc += 5
24
        else:
25
            ins.append((pc, op, None))
26
            pc += 1
27
    return ins
28

29
def main():
30
    blob = Path(BIN).read_bytes()
31
    prog = blob[va_to_off(PROG_VA):va_to_off(PROG_VA) + PROG_SIZE + 4]
32
    ins = decode_vm(prog, PROG_SIZE)
33

34
    stack = []
35
    def push(x): stack.append(x)
36
    def pop(): return stack.pop()
37
    def XOR(a, b):
38
        if a[0] == "const" and b[0] != "const":
39
            a, b = b, a
40
        return ("xor", a, b)
41
    def ADD(a, b):
42
        ta = a[1] if a[0] == "sum" else [a]
43
        tb = b[1] if b[0] == "sum" else [b]
44
        return ("sum", ta + tb)
45

46
    for _, op, imm in ins:
47
        if op == 0:
48
            push(("const", imm & 0xFFFFFFFF))
49
        elif op == 5:
50
            push(("byte", imm))
51
        elif op == 2:
52
            b = pop(); a = pop()
53
            push(XOR(a, b))
54
        elif op == 1:
55
            b = pop(); a = pop()
56
            push(ADD(a, b))
57

58
    final = stack[-1][1]
59
    c = [None] * 26
60

61
    for t in final:
62
        left, right = t[1], t[2]
63
        ci = right[1] & 0xFF
64
        a, b = left[1], left[2]
65
        i, j = a[1], b[1]
66
        if j == (i + 1) % 26:
67
            c[i] = ci
68
        else:
69
            c[j] = ci
70

71
    b = [0] * 26
72
    b[0] = ord("I")
73
    for i in range(25):
74
        b[i+1] = b[i] ^ c[i]
75

76
    print("".join(map(chr, b)))
77

78
if __name__ == "__main__":
79
    main()

Final Flag:

IDEH{I_h3Ckin_L0ooOv3_VM5}

Verify:

1
 echo -n "IDEH{I_h3Ckin_L0ooOv3_VM5}" | ./chall
2
# oui?
3
# OUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUIOUI

IDEH — Deception.exe

Category: Malware Analysis / Reverse Engineering / Misc

Flag format: IDEH{...}

Binary: Deception.exe

📎 Attachments

Deception.exe.zip

1) Executive Summary

Our SOC team detected a suspicious Windows executable named Deception.exe.
Static analysis revealed that the binary uses process-injection related APIs and contains an embedded encrypted payload.

By reversing the binary, we identified an RC4 decryption routine used to decrypt a hidden buffer stored in the .rdata section. Re-implementing this routine allowed us to recover the flag.

Step 1 — Initial Triage

Identify the file:

1
file Deception.exe

Output:

1
PE32+ executable (console) x86-64, for MS Windows

Hash for tracking:

1
sha256sum Deception.exe

1
50ecfaaefcd8b5b169123618169d9a0696dcbfa81f7991edb93bbb4128d676f8

PE inspection (DIE / PE-Studio / CFF Explorer):

Architecture: x64

Compiler: MinGW (GCC)

19 sections

Contains .debug_* DWARF sections

Unsigned binary

Step 2 — Suspicious Indicators

Imports analysis:

1
rabin2 -i Deception.exe

Interesting APIs:

CreateProcessA

ReadProcessMemory

WriteProcessMemory

VirtualProtect

VirtualQuery

NtQueryInformationProcess

ResumeThread

Strong indicators of process hollowing / injection malware.

Strings:

1
strings Deception.exe

Notable strings:

1
C:\Windows\System32\WerFault.exe
2
-u -p %d -s %d

Masquerading as Windows Error Reporting.

Step 3 — Reverse Engineering

Loaded into IDA.

Main findings:

main() calls a function initializing a 256-byte state array.

Performs byte swaps and modular indexing.

XORs a buffer with a generated keystream.

This exactly matches the RC4 algorithm (KSA + PRGA).

Step 4 — Extracting Key and Ciphertext

From .rdata, referenced directly by the RC4 function:

1
RC4 Key (9 bytes)
2
23 82 71 87 12 23 12 FF EE

Encrypted Buffer (27 bytes)

1
13 39 97 51 CA 44 49 D0 4B 89 10 F0 61 8A 27 74
2
50 F9 B6 52 9C 26 1E B4 E2 29 ED

Step 5 — Decryption Script

1
def rc4(key, data):
2
    S = list(range(256))
3
    j = 0
4

5
    # KSA
6
    for i in range(256):
7
        j = (j + S[i] + key[i % len(key)]) % 256
8
        S[i], S[j] = S[j], S[i]
9

10
    # PRGA
11
    i = j = 0
12
    out = bytearray()
13
    for b in data:
14
        i = (i + 1) % 256
15
        j = (j + S[i]) % 256
16
        S[i], S[j] = S[j], S[i]
17
        out.append(b ^ S[(S[i] + S[j]) % 256])
18

19
    return bytes(out)
20

21

22
key = bytes.fromhex("23827187122312ffee")
23
ct  = bytes.fromhex("13399751ca4449d04b8910f0618a277450f9b6529c261eb4e229ed")
24

25
print(rc4(key, ct))

Output:

1
IDEH{D3c3pt10n_h1d35_tru7h}

have fun … always ON TOP?!