Deskripsi Singkat

Pada challenge ini diberikan sebuah file binary bernama aktivasi_sistem. Binary tersebut merupakan modul aktivasi sistem yang meminta kode aktivasi sebelum memberikan akses. Tujuan dari challenge ini adalah menganalisis binary untuk menemukan kode aktivasi yang valid.

Analisis Awal

Langkah pertama yang saya lakukan adalah mengecek jenis file menggunakan perintah file.

file aktivasi_sistem

Hasilnya menunjukkan bahwa file tersebut merupakan ELF 64-bit executable. Selanjutnya, saya menjalankan binary untuk melihat perilakunya.

./aktivasi_sistem

Program menampilkan pesan:

Sistem Aktivasi PT Infrastruktur Digital
Masukkan kode aktivasi:

Jika input yang diberikan salah, program akan menampilkan pesan bahwa kode aktivasi tidak valid. Dari sini dapat disimpulkan bahwa program melakukan validasi terhadap input pengguna.

Kemudian saya melakukan pemeriksaan string menggunakan perintah:

strings aktivasi_sistem

Pada hasil strings, terdapat beberapa string yang terlihat seperti petunjuk, seperti:

INFRANET-V2
bypass_key_admin
kernel_token
SYS-AUTH-MODULE-v3.1

Namun string tersebut bukan kode aktivasi yang valid. Selain itu, terdapat string yang tampak tidak terbaca langsung:

<6;=!)k4=6i

Hal ini sesuai dengan catatan challenge bahwa string yang tidak terbaca langsung bukan berarti tidak ada informasi di dalamnya.

Langkah Penyelesaian

Untuk memahami cara program memvalidasi input, saya melakukan disassembly menggunakan objdump.

objdump -d -Mintel aktivasi_sistem

Dari hasil disassembly, ditemukan fungsi bernama xor_decode. Fungsi ini melakukan operasi XOR terhadap setiap byte menggunakan nilai 0x5a.

Potongan logic pentingnya adalah:

xor eax, 0x5a

Program mengambil data terenkripsi dari bagian .rodata, kemudian melakukan decode menggunakan XOR 0x5a. Hasil decode tersebut kemudian dibandingkan dengan input pengguna menggunakan fungsi strcmp.

Data terenkripsi yang digunakan sebagai kode aktivasi berada pada bagian .rodata:

3c 36 3b 3d 21 29 6b 34 3d 36 69 05 38 23 2e 69
05 22 6a 28 05 6e 39 2e 6b 2c 6e 2e 69 3e 27

Setelah mengetahui bahwa algoritmanya adalah single-byte XOR dengan key 0x5a, saya melakukan decode menggunakan Python.

enc = bytes.fromhex(
    "3c363b3d21296b343d36690538232e6905226a28056e392e6b2c6e2e693e27"
)

print(bytes([b ^ 0x5a for b in enc]).decode())

Hasil decode-nya adalah:

flag{s1ngl3_byt3_x0r_4ct1v4t3d}

Untuk memastikan kode tersebut benar, saya menjalankan kembali binary dan memasukkan hasil decode tersebut sebagai kode aktivasi.

./aktivasi_sistem

Input:

flag{s1ngl3_byt3_x0r_4ct1v4t3d}

Program kemudian menampilkan pesan:

Aktivasi berhasil! Sistem online.

Flag

flag{s1ngl3_byt3_x0r_4ct1v4t3d}

Kesimpulan / Hal yang Dipelajari

Pada challenge ini, kode aktivasi tidak disimpan secara langsung dalam bentuk plaintext. Program menyimpan kode tersebut dalam bentuk data yang telah di-XOR menggunakan key 0x5a, lalu mendecode-nya saat runtime sebelum dibandingkan dengan input pengguna.

Dari challenge ini, saya belajar bahwa pada reverse binary, hasil strings tidak selalu langsung menampilkan flag. String yang terlihat seperti petunjuk bisa saja hanya noise, sedangkan data penting dapat disimpan dalam bentuk terenkripsi atau ter-encode sederhana seperti single-byte XOR.

Deskripsi Singkat

Challenge W1-E1: Foto Mencurigakan merupakan challenge kategori Digital Forensics. Pada soal diberikan sebuah file gambar bernama foto_kantor.jpg dan file catatan analis readme_analis.txt. Dari catatan analis, diketahui bahwa foto tersebut kemungkinan mengandung file tersembunyi dan perlu diperiksa menggunakan tool forensik standar.

Analisis Awal

Langkah awal yang saya lakukan adalah membaca file readme_analis.txt. Di dalam catatan tersebut terdapat petunjuk bahwa gambar yang diberikan tidak hanya berisi tampilan visual biasa, tetapi kemungkinan menyimpan file lain di dalamnya. Karena challenge ini termasuk digital forensics dan berkaitan dengan gambar, saya mulai memeriksa metadata serta kemungkinan adanya teknik steganografi pada file foto_kantor.jpg.

Langkah Penyelesaian

Pertama, saya memeriksa metadata gambar menggunakan exiftool.

exiftool foto_kantor.jpg

Dari hasil pengecekan metadata, ditemukan komentar yang berisi password:

pass: kantor2026

Password ini menjadi petunjuk bahwa file gambar kemungkinan menggunakan teknik steganografi dengan password tertentu. Selanjutnya, saya mencoba mengekstrak file tersembunyi menggunakan steghide.

steghide extract -sf foto_kantor.jpg -p kantor2026

Setelah perintah tersebut dijalankan, berhasil diekstrak sebuah file bernama hidden.txt.

cat hidden.txt

Isi file tersebut menampilkan flag challenge.

Flag

flag{st3gh1d3_k4nt0r_2026_f0und}

Kesimpulan / Hal yang Dipelajari

Dari challenge ini, saya belajar bahwa file gambar tidak selalu hanya berisi data visual yang terlihat oleh mata. Informasi penting dapat disembunyikan di dalam metadata maupun menggunakan teknik steganografi. Pada kasus ini, metadata gambar menyimpan password yang kemudian digunakan untuk mengekstrak file tersembunyi menggunakan steghide.

Deskripsi Singkat

Pada challange ini diberikan website Portfolio Budi Santoso, dan menurut instruksi ada informasi sensitif yang tersebar. Catatan dari tantangan ini memberitahukan bahwa flag bukan hanya ada di tampilan atau halaman utama.

Analisis Awal

Saya melakukan analisis pada bagian front end website. Kemudian di halaman /whois_dump.txt saya menemukan potongan flag part 2 yang di-encoding dengan base64.

=RfYjRzMzY0X2NoNDFufQ==

Pemeriksaan secara backend dilakukan. Dari kode halaman utama ditemukan komentar tentang adanya halaman yang disembunyikan.

<!-- halaman pribadi: /catatan.html -->

Di halaman catatan.html ditemukan bagian 1 dari flag:

ZmxhZ3t0dzBfZnI0Z20zbn

Langkah Penyelesaian

1. Buka terminal linux
2. Gabungkan part 1 dan 2 dari flag:

ZmxhZ3t0dzBfZnI0Z20zbnRfYjRzMzY0X2NoNDFufQ==

1. Decode dengan tool base64:

Flag

flag{tw0_fr4gm3nt_b4s364_ch41n}

Kesimpulan / Hal yang Dipelajari

Dari challenge ini, saya belajar bahwa informasi penting pada website tidak selalu terlihat di halaman utama. Dengan memeriksa source code, halaman tersembunyi, dan file tambahan seperti /whois_dump.txt, saya dapat menemukan dua bagian flag. Kedua bagian tersebut kemudian digabungkan dan didecode menggunakan base64 untuk mendapatkan flag akhir.

Deskripsi Singkat

Pada challenge ini diberikan sebuah file binary blob konfigurasi dari perangkat IoT yang diduga telah dikompromikan. Bersama file tersebut, terdapat catatan analis dan potongan source code yang menjelaskan cara data konfigurasi diproses. Tujuan dari challenge ini adalah memahami struktur file binary, menemukan kunci enkripsi, lalu mendecode isi konfigurasi hingga mendapatkan flag.

Analisis Awal

Langkah pertama yang saya lakukan adalah membaca file key_hint.txt. Dari catatan tersebut diketahui bahwa 4 byte pertama pada file config.bin merupakan XOR key. Nilai pada offset 0x00-0x03 adalah:

4B 33 61 5F

Jika dikonversi dari hexadecimal ke ASCII, nilai tersebut menjadi:

K3a_

Selanjutnya, saya membaca file partial_source.c. Dari potongan source code tersebut terlihat bahwa program membaca 4 byte pertama sebagai key, lalu melewati 4 byte awal file sebelum melakukan proses decode. Data setelah offset 0x04 di-XOR menggunakan key 4-byte secara berulang atau siklik.

Catatan pada soal berbunyi:

"Dalam analisis biner, yang tampak jelas seringkali adalah pengalih perhatian."

Petunjuk ini menunjukkan bahwa tidak cukup hanya melihat string yang tampak langsung dari file binary. Isi sebenarnya perlu didecode terlebih dahulu menggunakan algoritma yang sesuai dengan source code yang diberikan.

Langkah Penyelesaian

Pertama, saya membuka file petunjuk untuk mengetahui struktur config.bin. Struktur file tersebut adalah:

[0x00-0x03] : 4-byte XOR key
[0x04-EOF ] : XOR-encoded strings

Dari struktur tersebut, saya mengambil 4 byte pertama sebagai key, yaitu:

4B 33 61 5F

Kemudian, saya membuat script Python sederhana untuk membaca file config.bin, mengambil key dari 4 byte pertama, lalu mendecode seluruh data setelah offset 0x04 dengan operasi XOR.

Script yang digunakan:

from pathlib import Path

data = Path("config.bin").read_bytes()

key = data[:4]
enc = data[4:]

dec = bytes(b ^ key[i % 4] for i, b in enumerate(enc))

for s in dec.split(b"\x00"):
    if s:
        print(s.decode())

Script tersebut bekerja dengan cara:

1. Membaca seluruh isi config.bin.
2. Mengambil 4 byte pertama sebagai XOR key.
3. Mengambil data setelah 4 byte pertama sebagai data terenkripsi.
4. Melakukan XOR setiap byte data dengan key secara berulang.
5. Memisahkan hasil decode berdasarkan null byte 0x00, karena setiap string diakhiri dengan null terminator.

Setelah script dijalankan, muncul beberapa string konfigurasi seperti alamat server, endpoint internal, dan satu string flag.

Hasil decode yang ditemukan:

192.168.47.23:8080
http://update.telematika-nusantara.internal/api/v1/beacon
vpn-gw.telematika-nusantara.internal
L2FwaS92Mi9iZWFjb24vdXBkYXRl
c2-backup.telematika.net:443
flag{xor_k3y_K33l_3xtr4ct3d}

Dari hasil tersebut, string terakhir merupakan flag challenge.

Flag

flag{xor_k3y_K33l_3xtr4ct3d}

Kesimpulan / Hal yang Dipelajari

Pada challenge ini saya mempelajari bahwa file binary tidak selalu dapat dianalisis hanya dengan melihat string yang tampak secara langsung. Informasi penting bisa disimpan dalam bentuk encoded atau encrypted. Dengan membaca catatan analis dan memahami potongan source code, dapat diketahui bahwa file config.bin menggunakan XOR encryption sederhana dengan key yang disimpan pada 4 byte pertama file. Setelah key ditemukan dan proses XOR dilakukan secara benar, isi konfigurasi berhasil didecode dan flag dapat ditemukan.

Deskripsi Singkat

Pada challenge ini, diberikan sebuah teks terenkripsi yang diduga merupakan korespondensi internal dari PT Arkana Sistem. Tugas utama dari challenge ini adalah menemukan metode enkripsi yang digunakan, mencari kunci dekripsi, lalu mendekripsi pesan untuk mendapatkan flag.

Analisis Awal

Langkah pertama yang saya lakukan adalah membaca file readme.txt. Dari file tersebut diketahui bahwa pesan dienkripsi menggunakan metode klasik, dan kunci dekripsi dapat ditemukan pada salah satu file lain di dalam archive. Readme juga memberikan petunjuk untuk memeriksa data yang tidak terlihat secara visual.

Selanjutnya, saya membuka file cipher_text.txt. Isi file tersebut berupa teks acak dengan huruf kapital, tetapi susunannya masih menyerupai format surat atau korespondensi. Di dalam teks tersebut juga terdapat bagian yang terlihat seperti flag, yaitu:

SLAX{F1G3A3R3_4RB4X4_D3PRYGD3D}

Bagian ini kemungkinan besar merupakan flag yang masih terenkripsi. Karena readme menyebutkan bahwa kunci ada pada file lain dan perlu memeriksa data yang tidak terlihat secara visual, saya kemudian mengecek metadata dari file company_logo.jpg.

Langkah Penyelesaian

1. Membaca file readme.txt untuk mencari petunjuk awal.
2. Dari readme, diketahui bahwa:
   • Cipher yang digunakan adalah metode klasik
   • Kunci berada di salah satu file lain
   • Perlu memeriksa data tersembunyi atau metadata
3. Mengecek metadata gambar company_logo.jpg menggunakan perintah:

exiftool company_logo.jpg

1. Dari metadata gambar ditemukan komentar:

kunci: ARKANA

1. Karena kunci berupa kata, metode klasik yang sesuai adalah Vigenere Cipher.
2. Melakukan dekripsi isi cipher_text.txt menggunakan Vigenere Cipher dengan key:

ARKANA

1. Setelah didekripsi, teks menjadi terbaca sebagai korespondensi internal. Bagian flag yang awalnya:

SLAX{F1G3A3R3_4RB4X4_D3PRYGD3D}

berubah menjadi:

FLAG{V1G3N3R3_4RK4N4_D3CRYPT3D}

1. Karena instruksi challenge meminta submit flag dalam format huruf kecil, maka flag diubah menjadi lowercase.

Flag

flag{v1g3n3r3_4rk4n4_d3crypt3d}

Kesimpulan / Hal yang Dipelajari

Dari challenge ini, saya belajar bahwa pada soal kriptografi, petunjuk tidak selalu berada langsung di file ciphertext. File pendukung seperti gambar juga bisa menyimpan informasi penting melalui metadata. Selain itu, ketika sebuah cipher klasik menggunakan kunci berupa kata, salah satu metode yang perlu dicoba adalah Vigenere Cipher. Pada challenge ini, key ARKANA berhasil digunakan untuk mendekripsi pesan dan mendapatkan flag.

Deskripsi Singkat

Pada challenge W1-E2: Lalu Lintas Jaringan, diberikan sebuah file capture bernama traffic.pcap. File ini berisi rekaman lalu lintas jaringan dari workstation yang dicurigai melakukan komunikasi tidak sah dengan server eksternal. Tujuan dari challenge ini adalah menganalisis traffic tersebut dan menemukan data tersembunyi yang mengarah ke flag.

Analisis Awal

Langkah pertama yang saya lakukan adalah membuka file traffic.pcap menggunakan Wireshark. Dari hasil pengamatan awal, terlihat bahwa traffic berisi beberapa komunikasi HTTP biasa, seperti akses ke website umum, request status API, request ping internal, dan komunikasi ke beberapa endpoint.

Untuk mempercepat analisis, saya juga menggunakan perintah strings agar dapat melihat teks yang terbaca langsung dari file PCAP.

strings traffic.pcap

Dari hasil tersebut terlihat beberapa request HTTP, salah satunya menuju host berikut:

backend.siluman-tech.id

Host ini terlihat mencurigakan karena terdapat beberapa endpoint yang tidak umum, seperti:

/api/submit
/session/refresh
/api/c2/beacon
/update/check

Selain itu, ditemukan juga beberapa data yang terlihat seperti Base64.

Langkah Penyelesaian

Pada awalnya ditemukan request berikut:

POST /api/submit HTTP/1.1
Host: backend.siluman-tech.id

user_id=EMP3391&action=check_in&secret_token=c2VjcmV0XzRiOGYyYzlkMWE2ZTNmN2IwYzVkMmU4YTlmNGIxYzdl

Nilai secret_token tersebut terlihat seperti Base64, sehingga saya mencoba melakukan decode.

echo 'c2VjcmV0XzRiOGYyYzlkMWE2ZTNmN2IwYzVkMmU4YTlmNGIxYzdl' | base64 -d

Hasilnya:

secret_4b8f2c9d1a6e3f7b0c5d2e8a9f4b1c7e

Namun hasil tersebut bukan flag, melainkan hanya token atau petunjuk lain. Karena challenge menyebutkan adanya data yang disembunyikan dalam lalu lintas normal, saya melanjutkan analisis ke request lain yang terlihat lebih mencurigakan.

Kemudian ditemukan komunikasi berikut:

POST /api/c2/beacon HTTP/1.1
Host: backend.siluman-tech.id
Content-Type: application/json
X-Client-ID: SLM-EMP3391

{"host":"WS-3391","os":"win10","ts":1748000000}

Endpoint /api/c2/beacon cukup mencurigakan karena istilah C2 biasanya merujuk pada Command and Control, yaitu komunikasi antara client yang terinfeksi dengan server pengendali.

Response dari server berisi data berikut:

HTTP/1.1 200 OK
Content-Type: application/json
X-Request-ID: c2-20260528-9f3a

{"status":"ok","task":"idle","ref":"ZmxhZ3twY2FwX2MyX3IzZl9iNHMzNjRfM3hmMWx9"}

Pada bagian response terdapat field ref yang berisi string Base64:

ZmxhZ3twY2FwX2MyX3IzZl9iNHMzNjRfM3hmMWx9

String tersebut kemudian saya decode menggunakan perintah:

echo 'ZmxhZ3twY2FwX2MyX3IzZl9iNHMzNjRfM3hmMWx9' | base64 -d

Hasil decode-nya adalah:

flag{pcap_c2_r3f_b4s364_3xf1l}

Dari sini dapat disimpulkan bahwa flag disembunyikan pada response komunikasi C2 dalam field ref, lalu diencoding menggunakan Base64.

Flag

flag{pcap_c2_r3f_b4s364_3xf1l}

Kesimpulan / Hal yang Dipelajari

Pada challenge ini, flag tidak muncul secara langsung di tampilan traffic biasa. Data penting disamarkan dalam komunikasi HTTP yang terlihat normal, tepatnya pada response endpoint /api/c2/beacon. Dari challenge ini dipelajari bahwa dalam analisis PCAP, kita tidak hanya perlu melihat request yang terlihat mencurigakan, tetapi juga perlu memeriksa response server, parameter tersembunyi, header, serta data yang tampak seperti hasil encoding. Base64 sering digunakan untuk menyamarkan data agar tidak langsung terbaca.

Deskripsi Singkat

Pada challenge ini diberikan sebuah website manajemen berkas internal milik PT Cahaya Nusantara. Website tersebut digunakan untuk menampilkan beberapa dokumen internal seperti halaman beranda, dokumen, laporan, dan panduan.

Dari narasi soal dijelaskan bahwa sistem menggunakan parameter URL untuk menentukan berkas yang ditampilkan. Catatan soal juga memberikan petunjuk bahwa validasi yang tidak sempurna dapat membuka akses ke seluruh sistem. Berdasarkan petunjuk tersebut, kemungkinan besar terdapat celah pada proses pembacaan file melalui parameter URL.

Analisis Awal

Saat membuka halaman utama, terlihat bahwa website menampilkan isi file welcome.txt. Pada menu navigasi, setiap halaman dipanggil menggunakan parameter page, contohnya:

?page=welcome.txt
?page=dokumen.txt
?page=laporan.txt
?page=panduan.txt

Hal ini menunjukkan bahwa aplikasi membaca file berdasarkan nilai dari parameter page.

Kemudian saya memeriksa source code halaman dan menemukan komentar HTML berikut:

<!-- Konfigurasi: lihat /var/www/html/config.php untuk referensi path flag_file -->

Komentar tersebut menjadi petunjuk penting karena memberitahu bahwa file konfigurasi berada di:

/var/www/html/config.php

Selain itu, file tersebut juga disebut berisi referensi menuju lokasi file flag.

Langkah Penyelesaian

Langkah pertama adalah mencoba membaca file config.php menggunakan teknik path traversal melalui parameter page.

Payload yang digunakan:

?page=../../../../var/www/html/config.php

Setelah payload tersebut dijalankan melalui browser, isi file config.php berhasil ditampilkan. Di dalam file tersebut ditemukan konfigurasi berikut:

<?php
// config.php  -  Konfigurasi Sistem Manajer Berkas Internal
// File ini berisi konfigurasi path dan pengaturan aplikasi.

// Path ke direktori halaman
define('PAGES_DIR', '/var/www/html/pages/');

// Path token autentikasi sistem
$flag_file = '/var/www/private/flag.txt';

// Pengaturan tampilan
define('APP_NAME', 'Manajer Berkas Internal');
define('APP_VERSION', '1.4.2');
define('COMPANY', 'PT Cahaya Nusantara');

Dari file konfigurasi tersebut, diketahui bahwa lokasi flag berada di:

/var/www/private/flag.txt

Setelah mengetahui lokasi flag, saya kembali menggunakan parameter page untuk membaca file tersebut:

?page=../../../../var/www/private/flag.txt

Payload tersebut berhasil menampilkan isi file flag pada halaman website. Setelah flag didapatkan, flag kemudian disubmit ke platform dan berhasil diterima.

Flag

DSG{...}

Kesimpulan / Hal yang Dipelajari

Challenge ini memanfaatkan kerentanan Local File Inclusion atau Path Traversal. Kerentanan terjadi karena aplikasi menerima input dari parameter page untuk menentukan file yang akan dibaca, tetapi tidak membatasi akses hanya ke direktori file yang seharusnya.

Akibatnya, pengguna dapat menggunakan pola ../ untuk keluar dari direktori halaman dan membaca file lain di server, termasuk file konfigurasi dan file flag. Dari challenge ini dapat dipelajari bahwa validasi path sangat penting pada fitur pembacaan file. Aplikasi seharusnya menggunakan whitelist file yang boleh diakses, membatasi direktori kerja, serta mencegah penggunaan traversal sequence seperti ../.

Deskripsi Singkat

Pada challenge W1-D3: Pemeriksa Kredensial, diberikan sebuah binary bernama pemeriksa_kredensial. Binary ini meminta input kredensial, lalu menentukan apakah input tersebut benar atau salah. Tujuan dari challenge ini adalah melakukan analisis reverse engineering untuk mengetahui kredensial yang valid.

Analisis Awal

Pertama, saya menjalankan pengecekan awal terhadap binary menggunakan perintah file.

file pemeriksa_kredensial

Hasilnya menunjukkan bahwa file merupakan binary ELF 64-bit untuk Linux dan tidak ter-strip, sehingga nama fungsi masih dapat terlihat saat dianalisis.

Selanjutnya, saya menggunakan strings untuk melihat string yang tersimpan di dalam binary.

strings pemeriksa_kredensial

Dari hasil tersebut ditemukan beberapa string menarik seperti:

ADMIN-CREDENTIAL-2026
ROOT-ACCESS-TOKEN
fWQza2M0cmNfbjE0aGNfNDYzczRiXzNzcjN2M3J7Z2FsZg==

Dua string pertama terlihat seperti kredensial, tetapi kemungkinan hanya decoy atau pengalih perhatian. String ketiga terlihat seperti Base64 karena memiliki pola karakter Base64 dan diakhiri dengan tanda ==.

Langkah Penyelesaian

Binary kemudian dianalisis lebih lanjut menggunakan objdump.

objdump -d -Mintel pemeriksa_kredensial

Dari fungsi main, ditemukan bahwa program melakukan beberapa proses terhadap input pengguna. Alurnya adalah:

1. Program menerima input dari user.
2. Karakter newline dihapus.
3. Input dibalik menggunakan fungsi reverse_str.
4. Hasil reverse kemudian di-encode menggunakan fungsi b64_encode.
5. Hasil encoding dibandingkan dengan string Base64 yang tersimpan di binary.

String pembanding yang ditemukan adalah:

fWQza2M0cmNfbjE0aGNfNDYzczRiXzNzcjN2M3J7Z2FsZg==

Karena program melakukan proses:

input → reverse → base64 encode → compare

maka untuk mendapatkan input asli, urutan tersebut harus dibalik:

base64 decode → reverse

Saya menggunakan Python untuk melakukan decoding.

python3 -c 'import base64; s="fWQza2M0cmNfbjE0aGNfNDYzczRiXzNzcjN2M3J7Z2FsZg=="; print(base64.b64decode(s).decode())'

Hasil decode Base64:

}d3kc4rc_n14hc_463s4b_3sr3v3r{galf

Hasil tersebut masih dalam kondisi terbalik, sehingga perlu dibalik lagi.

python3 -c 'import base64; s="fWQza2M0cmNfbjE0aGNfNDYzczRiXzNzcjN2M3J7Z2FsZg=="; print(base64.b64decode(s).decode()[::-1])'

Hasil akhirnya adalah:

flag{r3v3rs3_b4s364_ch41n_cr4ck3d}

Setelah input tersebut dimasukkan ke program, binary menampilkan pesan bahwa kredensial benar dan akses diberikan.

printf 'flag{r3v3rs3_b4s364_ch41n_cr4ck3d}\n' | ./pemeriksa_kredensial

Output:

Kredensial benar! Akses diberikan.

Flag

flag{r3v3rs3_b4s364_ch41n_cr4ck3d}

Kesimpulan / Hal yang Dipelajari

Pada challenge ini, flag tidak langsung tersimpan dalam bentuk plaintext. Binary melakukan beberapa lapisan transformasi, yaitu membalik input lalu melakukan encoding Base64 sebelum membandingkannya dengan nilai yang sudah disimpan. Dari challenge ini dipelajari bahwa saat melakukan reverse engineering, penting untuk memahami urutan transformasi yang dilakukan program. Untuk mendapatkan nilai asli, proses tersebut harus dibalik dengan urutan yang berlawanan.

Deskripsi Singkat

Pada challenge ini diberikan sebuah binary bernama perangkat_lunak_terkunci. Binary tersebut merupakan program verifikasi lisensi yang meminta input berupa kunci lisensi. Tujuan dari challenge ini adalah menganalisis cara program memvalidasi input, lalu menemukan license key yang benar agar program berhasil diaktifkan.

Analisis Awal

Pertama, binary dijalankan untuk melihat perilakunya.

./perangkat_lunak_terkunci

Program meminta input lisensi. Jika input salah, program akan menampilkan pesan bahwa lisensi tidak valid. Berdasarkan catatan soal, nilai yang tersimpan di dalam binary kemungkinan tidak disimpan dalam bentuk asli, sehingga perlu dianalisis menggunakan teknik reverse engineering sederhana.

Selanjutnya dilakukan pengecekan string yang ada di dalam binary.

strings perangkat_lunak_terkunci

Dari hasil pengecekan ditemukan sebuah string panjang berbentuk hexadecimal:

666c61677b6833785f737472316e675f6c3163336e73335f637234636b33647d

String tersebut terlihat seperti data yang sudah di-encode, bukan teks biasa.

Langkah Penyelesaian

Karena string yang ditemukan berbentuk hexadecimal, langkah berikutnya adalah melakukan decode dari hex ke ASCII.

Decode dapat dilakukan menggunakan command berikut:

echo "666c61677b6833785f737472316e675f6c3163336e73335f637234636b33647d" | xxd -r -p

Hasil decode-nya adalah:

flag{h3x_str1ng_l1c3ns3_cr4ck3d}

Setelah itu, hasil decode tersebut dicoba sebagai input lisensi ke program.

./perangkat_lunak_terkunci

Kemudian masukkan:

flag{h3x_str1ng_l1c3ns3_cr4ck3d}

Program memberikan output bahwa lisensi valid dan perangkat lunak berhasil diaktifkan. Ini membuktikan bahwa string hexadecimal di dalam binary adalah license key yang benar setelah didecode.

Flag

flag{h3x_str1ng_l1c3ns3_cr4ck3d}

Kesimpulan / Hal yang Dipelajari

Pada challenge ini, validasi lisensi dilakukan dengan membandingkan input pengguna dengan nilai yang sudah disimpan di dalam binary dalam bentuk hexadecimal. Dari challenge ini dapat dipelajari bahwa pada reverse engineering, string penting seperti password, key, atau flag tidak selalu disimpan dalam bentuk plaintext, tetapi bisa disamarkan menggunakan encoding sederhana seperti hex.

Deskripsi Singkat

Pada challenge ini, diberikan sebuah website milik PT Siluman Teknologi. Berdasarkan narasi soal, data sensitif perusahaan diduga bocor dan tersebar di beberapa lokasi digital. Tujuan dari challenge ini adalah menelusuri jejak-jejak yang tersedia pada website untuk menemukan komponen yang diperlukan dalam proses mendapatkan flag.

Analisis Awal

Langkah pertama dilakukan dengan membuka halaman utama PT Siluman Teknologi. Pada halaman tersebut terdapat daftar tim teknis unggulan dan sebuah tautan untuk mengunduh direktori karyawan dalam bentuk file employee_list.csv.

Dari file CSV tersebut ditemukan beberapa data karyawan seperti nama, divisi, email, status, dan blog pribadi. Salah satu entri yang menarik adalah Ahmad Fauzi, seorang Senior Security Engineer dengan ID karyawan EMP-3391, yang memiliki blog pribadi bernama aftech.html.

Selain itu, pengecekan terhadap robots.txt juga memberikan petunjuk penting karena terdapat beberapa path yang tidak diperbolehkan untuk diindeks, salah satunya adalah /leaked_env.txt. File ini menjadi petunjuk kuat karena halaman utama juga menyebutkan adanya potensi kebocoran file konfigurasi.

Langkah Penyelesaian

Pertama, saya membuka file employee_list.csv dari halaman utama. File tersebut berisi data karyawan PT Siluman Teknologi. Dari file ini ditemukan bahwa Ahmad Fauzi memiliki blog pribadi dengan path:

aftech.html

Setelah membuka halaman aftech.html, terdapat petunjuk bahwa file gambar sering menyimpan informasi lebih dari yang terlihat, khususnya melalui metadata. Pada halaman tersebut juga terdapat gambar profil Ahmad Fauzi dengan nama file:

profile_ahmad.jpg

Selanjutnya, saya membuka file robots.txt dan menemukan beberapa path tersembunyi:

/internal/
/admin/
/leaked_env.txt

Path yang paling relevan adalah /leaked_env.txt karena berhubungan dengan kebocoran konfigurasi. Setelah dibuka, file tersebut berisi konfigurasi API dan sebuah token terenkripsi:

API_TOKEN_ENC=VV9YViMEQmkCbEEGKUcuKFxBZlprTi5kQEAKXDpbQjRO

Dari petunjuk pada blog Ahmad Fauzi, saya kemudian memeriksa metadata gambar profile_ahmad.jpg. Pada metadata gambar ditemukan komentar:

kunci2: X7qP

Karena Ahmad Fauzi memiliki ID karyawan EMP-3391, maka bagian pertama kunci diambil dari ID tersebut, yaitu:

3391

Kemudian kunci kedua dari metadata adalah:

X7qP

Sehingga kunci lengkap yang digunakan adalah:

3391X7qP

Token API_TOKEN_ENC kemudian didecode dari Base64, lalu hasilnya didekripsi menggunakan XOR dengan kunci 3391X7qP. Dari proses tersebut didapatkan flag:

flag{3391_x7qp_xor_k3y_4ss3mbl3d}

Flag

flag{3391_x7qp_xor_k3y_4ss3mbl3d}

Kesimpulan / Hal yang Dipelajari

Challenge ini mengajarkan bahwa dalam OSINT, informasi penting tidak selalu terlihat langsung pada halaman utama. Petunjuk dapat tersebar di berbagai tempat seperti file CSV, robots.txt, file konfigurasi yang bocor, halaman blog pribadi, hingga metadata gambar. Selain itu, challenge ini juga menunjukkan pentingnya menggabungkan beberapa potongan informasi untuk mendapatkan kunci dekripsi yang benar.