Quantum Conundrum - Security Assessment Report#

Answer:#

Encoding Algorithm: Base64

Decoded Value: 24.07.2025|megacorp@quantum.com

What It Represents: A static string containing a date and email address used as input for seed generation in the encryption/decryption process.

Evidence Analysis:#

File Location: publickey.pubkey

Raw Contents (Base64-encoded):

1
MjQuMDcuMjAyNXxtZWdhY29ycEBxdWFudHVtLmNvbQ==

Decoding Process:

1
import base64
2

3
encoded = "MjQuMDcuMjAyNXxtZWdhY29ycEBxdWFudHVtLmNvbQ=="
4
decoded = base64.b64decode(encoded).decode('utf-8')
5
print(decoded)
6
# Output: 24.07.2025|megacorp@quantum.com

Structure Breakdown:

• Date Component: 24.07.2025 (Day.Month.Year format)
  • Day: 24
  • Month: 07 (July)
  • Year: 2025
• Separator: | (pipe character)
• Email Component: megacorp@quantum.com

Purpose in Encryption System: This decoded string serves as a static component of the seed generation algorithm. It combines with other dynamic elements (timestamp, salt) to create the encryption/decryption seed.

Why Base64?#

Characteristics:

• Standard encoding method (RFC 4648)
• Converts binary data to ASCII text
• Uses 64-character set: A-Z, a-z, 0-9, +, /
• Padding with = characters
• NOT encryption - purely encoding

Identification:

• Ends with == (padding indicator)
• Only contains alphanumeric characters and =
• No special characters or symbols

Security Implication: CRITICAL WEAKNESS

• Base64 is encoding, not encryption
• Provides zero security or obfuscation
• Trivially reversible
• Public key should use asymmetric cryptography (RSA, ECC), not simple encoding

Answer:#

Seed Calculation Uses:

1. Date from public key: 24.07.2025
2. Email from public key: megacorp@quantum.com
3. Secret string: PublicSalt
4. Timestamp from file: 2025-07-24T11:00:00Z

Seed Generation Algorithm:#

Formula:

1
seed = EMAIL + DATE + TIMESTAMP + SALT

Full Seed Example:

1
megacorp@quantum.com24.07.20252025-07-24T11:00:00ZPublicSalt

Components Breakdown:

How the Timestamp is Obtained:#

File Structure: The encrypted file (decrypt_me.enc) has a specific structure:

1
[Encrypted Data: N bytes] [Timestamp: variable length] [Metadata: 8 bytes]

Metadata Layout (last 8 bytes):

• Bytes -8 to -4: Timestamp length (4 bytes, little-endian integer)
• Bytes -4 to end: Matrix dimension N (4 bytes, little-endian integer)

Extraction Code:

1
data = Path("decrypt_me.txt.enc").read_bytes()
2
ts_len = int.from_bytes(data[-8:-4], "little")
3
n = int.from_bytes(data[-4:], "little")
4
timestamp = data[-8 - ts_len:-8].decode("ascii")

Example:

• If ts_len = 20 and n = 64
• Timestamp is stored at bytes [-28:-8]
• Value: 2025-07-24T11:00:00Z (ISO 8601 format)

Security Analysis:#

Weaknesses Identified:

1. Hardcoded Salt

   • PublicSalt is a constant, not truly random
   • Same salt used for all encryptions
   • Does not provide cryptographic security

2. Predictable Date

   • Date from public key is static
   • Known to anyone with access to public key
   • Reduces entropy of seed

3. ISO Timestamp Format

   • Standard format is predictable
   • Only changes per encryption instance
   • Limited entropy (time-based guessing possible)

4. No Key Derivation Function (KDF)

   • Simple concatenation, no PBKDF2/Argon2/scrypt
   • No computational hardness
   • Vulnerable to brute-force if seed guessed

Proper Implementation Should Use:

• Random salt per encryption
• Strong KDF (PBKDF2, Argon2, scrypt)
• High iteration count
• Additional entropy sources

Answer:#

Number of passes before the final XOR: 7

First Three Transformations:

1. Ring rotation: Rotates each concentric layer of the NN grid 90 clockwise. This physically rearranges the spatial layout by treating the matrix like onion rings, where each ring (outer, inner, etc.) rotates independently.

2. Add constant pass: Adds a byte constant (derived from year: 2025 & 0xFF = 225) to every cell modulo 256. This operation uniformly shifts all byte values across the entire matrix, providing initial value diffusion.

3. Subtract constant pass: Subtracts a byte constant (derived from month: 7) from every cell modulo 256. This reverses some of the addition effect while maintaining byte-level confusion, creating a non-linear relationship between original and transformed values.

Transformation 1: Ring Rotation (90 Clockwise)#

Location: Inline block in FUN_140002680

Algorithm:

1
For an NN matrix, treat as concentric rings
2
For each ring (outer to inner):
3
    Extract ring elements
4
    Rotate 90 clockwise
5
    Place back in matrix

Example (44 matrix):

1
Before Ring Rotation:
2
 1  2  3  4
3
 5  6  7  8
4
 9 10 11 12
5
13 14 15 16
6

7
After Ring Rotation:
8
13  9  5  1
9
14 10  6  2
10
15 11  7  3
11
16 12  8  4

Code Evidence:

• Complex loop structure manipulating matrix indices
• Processes rings from outermost to innermost
• Uses temporary storage for rotation

Purpose:

• Initial spatial scrambling
• Makes linear analysis impossible
• Each ring moves independently

Transformation 2: Add Constant (mod 256)#

Location: FUN_140002070

Algorithm:

1
add_val = year & 0xFF  # 2025 & 0xFF = 225
2
for each cell in matrix:
3
    cell = (cell + add_val) mod 256

Disassembled Code:

1
iVar9 = param_2 + *puVar6;
2
*puVar6 = iVar9 + ((int)((-(uint)(iVar9 < 0) & 0xff) + iVar9) >> 8) * -0x100;

Translation: (value + constant) & 0xFF

Example:

• Cell value: 50
• Add 225: 50 + 225 = 275
• Mod 256: 275 mod 256 = 19

Purpose:

• Uniform byte-level diffusion
• Changes all values simultaneously
• Modulo arithmetic prevents overflow

Transformation 3: Subtract Constant (mod 256)#

Location: FUN_1400021f0

Algorithm:

1
sub_val = month  # July = 7
2
for each cell in matrix:
3
    cell = (cell - sub_val + 256) mod 256

Disassembled Code:

1
iVar9 = (*puVar6 - param_2) + 0x100;
2
*puVar6 = iVar9 + ((int)((-(uint)(iVar9 < 0) & 0xff) + iVar9) >> 8) * -0x100;

Translation: (value - constant + 256) & 0xFF

Example:

• Cell value: 50
• Subtract 7: 50 - 7 + 256 = 299
• Mod 256: 299 mod 256 = 43

Purpose:

• Counter-intuitive: adds confusion after addition
• Non-linear transformation
• Different constant than add pass

Transformation 4: Row/Column Cyclic Shifts#

Location: FUN_140002390 (first part)

Algorithm:

1
shift = day % N  # 24 % 64 = 24
2
# Rotate rows
3
rows.rotate(-shift)
4
# Rotate columns
5
for each row:
6
    row.rotate(-shift)

Code Evidence:

1
lVar5 = (longlong)(param_2 % ((int)(lVar5 >> 2) - (int)(lVar5 >> 0x3f)));
2
// param_2 is day value, lVar5 is derived from matrix size

Visual Example (shift=2, 44):

1
Row shift left by 2:
2
[A B C D]  [C D A B]
3

4
Column shift up by 2:
5
[1]     [9]
6
[5]    [13]
7
[9]     [1]
8
[13]    [5]

Purpose:

• Positional permutation
• Doesn’t change byte values
• Based on date component (day)

Transformation 5: Transposition / Quadrant Swaps#

Location: Inline block after FUN_140002390

Algorithm:

1
Divide matrix into quadrants
2
Swap quadrants in specific pattern
3
May also transpose (swap rows/columns)

Code Pattern:

• Complex index manipulation
• Swapping uVar2 values between positions
• Multiple nested loops

Conceptual:

1
[TL TR]        [BR BL]
2
[BL BR]         [TR TL]

Purpose:

• Advanced geometric rearrangement
• Breaks up patterns from previous transforms
• Adds complexity layer

Transformation 6: Even/Odd Bit Swap (0x55 mask)#

Location: FUN_140002540

Algorithm:

1
def bit_flip_pairs(x):
2
    return ((x >> 1) & 0x55) | ((x & 0x55) << 1)

Disassembled Code:

1
*puVar3 = (int)*puVar3 >> 1 & 0x55U | (*puVar3 & 0x55) << 1;

Bit-level Transformation:

1
Original:  b b b b b b b b
2
After:     b b b b b b b b
3

4
Example byte: 10110011 (179)
5
Result:       01101101 (109)
6

7
Mask 0x55 = 01010101 (isolates odd bits)
8
Mask 0xAA = 10101010 (isolates even bits)

Purpose:

• Bit-level confusion
• Makes byte analysis harder
• Reversible transformation

Transformation 7: Per-Byte Variable Bit Rotation#

Location: Inline loop in FUN_140002680

Algorithm:

1
for r in range(N):
2
    for c in range(N):
3
        spin = (year + month + day + r + c) & 7
4
        cell = rot_right(cell, spin)
5

6
def rot_right(x, amt):
7
    amt &= 7  # 0-7 bits
8
    return ((x >> amt) | ((x << (8 - amt)) & 0xFF)) & 0xFF

Disassembled Code:

1
uVar41 = uVar44 & 0x80000007;  // rotation amount (0-7)
2
*(uint *)(...) = (iVar8 >> (8 - (byte)uVar41) | iVar8 << ((byte)uVar41)) & 0xff;

Example:

1
Position (2,3): rotation = (2025 + 7 + 24 + 2 + 3) & 7 = 5
2

3
Byte: 10110011
4
Rotate right 5 bits: 01101011

Purpose:

• Position-dependent obfuscation
• Final bit-level scrambling
• Each byte rotates differently

Answer:#

Flag: OS{BENDER}

Decryption Results:#

Full Plaintext Content:

1
[Decrypted poem/message containing the flag]

Flag Format: OS{...}

• Prefix: OS (OffSec)
• Content: BENDER
• Full flag: OS{BENDER}

Flag Location: Embedded within the decrypted plaintext message.

1. Public Key is Not a Key#

Issue: The file named publickey.pubkey is simply Base64-encoded data, not a cryptographic public key.

Expected: RSA/ECC public key in PEM/DER format Actual: Base64(24.07.2025|megacorp@quantum.com)

Impact:

• Anyone can decode and read the “key”
• No asymmetric cryptography
• Misleading naming suggests security that doesn’t exist

Fix: Use actual public-key cryptography (RSA 2048+, ECC P-256+)

2. Hardcoded Salt#

Issue: PublicSalt is a constant string, not a random per-encryption salt.

Problem:

• Same salt for all encryptions
• Known to attackers (found via reverse engineering)
• Defeats the purpose of salt (uniqueness)

Impact:

• Rainbow table attacks possible
• Pattern analysis across multiple encrypted files
• No protection against precomputation attacks

Fix: Generate random salt per encryption, store with ciphertext

3. No Key Derivation Function#

Issue: Seed is used directly via simple concatenation:

1
seed = EMAIL + DATE + TIMESTAMP + SALT

Missing:

• PBKDF2, Argon2, or scrypt
• Iteration count (computational hardness)
• Proper key stretching

Impact:

• Fast brute-force attempts
• No computational cost for attacker
• Weak derivation from password-like inputs

Fix: Implement proper KDF with 100,000+ iterations

4. Weak Keystream Generator#

Issue:

1
out.append((ord(ch) * 7 + idx) & 0xFF)

Problems:

• Simple arithmetic operation
• Not a cryptographically secure PRNG
• Predictable pattern
• Linear relationship

Impact:

• Statistical analysis possible
• Pattern detection in keystream
• Not quantum-resistant despite claims

Fix: Use ChaCha20, AES-CTR, or other approved stream cipher

5. Deterministic Encryption#

Issue: Same plaintext + same metadata = same ciphertext

Problem:

• Timestamp is only variable component
• If timestamp is known/controlled, encryption is identical

Impact:

• Replay attacks
• Ciphertext comparison reveals identical messages
• ECB-like weaknesses

Fix: Add random IV/nonce to each encryption