RACONF'26 — CTF WRITE-UP

Bu yazı RACONF’26 CTF yarışmasında çözdüğüm 6 challenge’ın WRITE-UP’larını tek belgede topluyor. Her bölüm kendi içinde bağımsız — doğrudan ilgilendiğin challenge’a atlayabilirsin.

---

01 — Aurora Industries

Çözüm; gizli fallback arayüzünün keşfi, log sızıntısından parola elde edilmesi, rol yükseltme ve kırık UI arkasında hâlâ çalışan backend endpoint’inin doğrudan tetiklenmesi üzerine kurulu.

Hedef

Node 7 üzerindeki kilidi kaldırıp son çıktıyı almak.

Kısa Özet

Çözüm zinciri şu şekilde ilerliyor:

1. Node 7 normal arayüzde çevrimdışı görünüyor.
2. node.php?id=7 ile açılan fallback dosya sistemi görünümünde log sızıntısı bulunuyor.
3. Loglardan bubirsifredir değeri elde ediliyor.
4. edit_profile.php endpoint’inde role değeri değiştirilebiliyor, ancak auth_key zorunlu.
5. Hata mesajı sayesinde auth_key alanının base64 formatı beklediği anlaşılıyor.
6. operator kullanıcısı admin yapılıyor.
7. operations.php endpoint’ine doğrudan POST atılarak Node 7 tekrar çevrimiçi hale getiriliyor.

Adım Adım Çözüm

1. Node 7’nin varlığını ve durumunu doğrulama

Başlangıç ekranında node.php?id=6 açık. Sağ taraftaki listede Node 7 görünse de durumu ÇEVRİMDIŞI. Bu, sistemde tanımlı ama standart akışla erişilemeyen ek bir bileşen olduğunu gösteriyor.

2. Fallback arayüzünü açma

node.php?id=7 sayfasına gidince normal panel yerine bozuk bir fallback arayüzü geliyor. Bu ekran aslında dosya sistemi benzeri bir görünüm sunuyor ve legacy/logs/logs.txt dosyasını okumaya izin veriyor.

Log içinde öne çıkan satırlar:

• operator token rejected
• waiting for hidden command channel...
• [BLOB] password=bubirsifredir

Üçüncü satır, doğrudan kullanılabilir bir credential sızdırıyor.

3. Sızan parolayı çıkarma

Kritik değer:

bubirsifredir

Bu değer sonraki adımda auth_key olarak deneniyor.

4. Profil güncelleme akışını inceleme

edit_profile.php sayfası operator kullanıcısının rolünü değiştirmeye izin veriyor gibi görünüyor. Ancak ilk denemede Auth key is required. hatası dönüyor. Bu da backend’in rol değişimini işlediğini, fakat ek bir doğrulama beklediğini gösteriyor.

5. İsteği yakalayıp ilk rol yükseltme denemesini yapma

İstek Burp ile yakalanıp body şu hale getiriliyor:

display_name=operator&role=admin&auth_key=bubirsifredir

Amaç, loglardan sızan değeri kullanarak rolü admin yapmak.

6. Hata mesajından beklenen formatı öğrenme

Sunucu doğrudan yanlış değer demiyor; bunun yerine şu hatayı döndürüyor:

base64 formatında olmalıdır

Bu mesaj, auth_key değerinin mantıksal olarak doğru olabileceğini ama önce base64 formatına çevrilmesi gerektiğini söylüyor.

7. Parolayı base64’e çevirip tekrar gönderme

Parola şu şekilde encode ediliyor:

echo -n 'bubirsifredir' | base64

Çıktı:

YnViaXJzaWZyZWRpcg==

Yeni request body:

display_name=operator&role=admin&auth_key=YnViaXJzaWZyZWRpcg==

8. Admin yetkisini alma

Bu istekten sonra operator kullanıcısının rolü admin oluyor.

Başarı göstergeleri:

• Mevcut Rol: admin
• Profile updated successfully.

9. Operations panelini inceleme

operations.php ekranına geçildiğinde sistem şu durumu gösteriyor:

• aktif kullanıcı operator (Rol: admin)
• hedef Node 7 durumu [ LOCKED ]
• POST alıcısı (Backend Endpoint) dinlemeye devam ediyor.

Arayüz bozuk olsa da aksiyonu tetikleyen backend endpoint açık kalmış — asıl zafiyet bu.

10. Eksik buton yerine doğrudan POST atma

Arayüz buton basmaya izin vermediği için istek Burp üzerinden manuel gönderiliyor:

hedef=node7

Bu body, normalde arayüzdeki eksik butonun yapacağı işi doğrudan backend’e yaptırıyor.

11. Node 7’yi açma ve son çıktıyı alma

İstekten sonra sistem şu mesajı basıyor:

CRITICAL: Node 7 kilitleri bypass edildi!

Durum:

Hedef: Node 7 durumu [ ONLINE ]

Ekranda görünen son çıktı:

RKN{YXJhbWL6ZGFu}

Sonuç

Bu challenge’daki ana zafiyet zinciri şuydu:

1. Erişime açık bırakılmış fallback görünümü
2. Log sızıntısı ile hassas veri ifşası
3. Yetersiz korunan rol güncelleme endpoint’i
4. Kırık arayüze rağmen açık kalan operasyon backend’i

Pratik çözüm özeti:

password = bubirsifredir
auth_key = YnViaXJzaWZyZWRpcg==
POST /operations.php
hedef=node7

Nihai çıktı: RKN{YXJhbWL6ZGFu}

---

02 — Nova Media Network

Sosyal medya ve açık kaynak izlerini birbirine bağlayan bir OSINT zinciri. Bir X hesabından bir Spotify referansına, oradan GitHub’daki silinmiş bir commit’e, son olarak da görsel metadata’sına uzanan bir yol.

Hedef

astro_jou761 ipucundan başlayarak flag’in gizlendiği EXIF alanını bulmak.

Kısa Özet

1. astro_jou761 X hesabı bulunuyor.
2. Hesaptaki paylaşım Space Oddity parçasına yönlendiriyor.
3. Bu keyword ile GitHub’da major-tom761/space-oddity reposu bulunuyor.
4. Commit geçmişinde silinmiş bir görsel dosyası tespit ediliyor.
5. Eski commit’ten geri alınan görselin EXIF metadata’sı inceleniyor.
6. Author alanında flag çıkıyor.

Adım Adım Çözüm

1. astro_jou761 hesabını bulma

astro_jou761 aramasında aynı kullanıcı adına ait X paylaşımları çıkıyor. Öne çıkan detay:

• paylaşım metni: “Her şey göründüğü gibi değil. Sinyal zayıf ama hâlâ buradayım.”

Bu kullanıcı, zincirdeki ilk somut OSINT noktası oluyor.

2. X paylaşımındaki ipucunu takip etme

Paylaşımda Spotify linki var, parça Space Oddity - 1999 Remaster. Etiketler: #orbit #signal #nova.

Kritik ipucu doğrudan Space Oddity — bir sonraki adımda bu başlık üzerinden arama yapmak mantıklı hale geliyor.

3. GitHub üzerinde Space Oddity izini sürme

Space Oddity GitHub’da aratıldığında major-tom761/space-oddity reposu çıkıyor:

1. repo adı doğrudan paylaşımdaki şarkı adıyla eşleşiyor
2. kullanıcı adı major-tom761, parçadaki Major Tom referansıyla uyumlu

Challenge bu noktada sosyal medya ipucundan açık kaynak izine bağlanmış oluyor.

4. Repo içeriğini inceleme

Repo içinde görülen dosyalar: LostInOrbit, NovaSignal, README.md, SpaceTracking, ground-control-to-major-tom. Dosya isimleri aynı temayı sürdürüyor.

Buradan sonra en mantıklı adım commit geçmişine bakmak — bu tarz sorularda flag çoğu zaman silinmiş içerik ya da eski bir revision içinde kalıyor.

5. Commit geçmişinde silinmiş dosyayı bulma

Commit 0a5ce56 içinde tek değişiklik ahtopot.jpg dosyasının silinmesi (-150 KB). Canlı branch’te dosya yok ama commit geçmişinden parent revision üzerinden geri alınabilir.

6. Silinmiş görseli geri alıp inceleme

Silinmiş ahtopot.jpg eski commit’ten geri alındığında görselin bir ahtapot fotoğrafı olduğu görülüyor. Görsel doğrudan flag vermiyor — sonraki adım EXIF metadata analizi.

Kullanılan araçlar: exiftool, strings, gerekirse hex incelemesi.

7. EXIF metadata içinden flag’i alma

exiftool çıktısında:

Author: RKN{saV9raXppX2}

Flag doğrudan görselin Author EXIF alanına gömülmüş.

Sonuç

Zincirin her halkası bir öncekinin bıraktığı ipucuna dayanıyor:

1. astro_jou761 → X paylaşımı
2. Space Oddity keyword → GitHub reposu
3. Commit geçmişi → silinmiş ahtopot.jpg
4. exiftool → EXIF Author alanı → flag

Nihai flag: RKN{saV9raXppX2}

---

03 — kepler10b.apk

Uygulama ilk bakışta birkaç farklı yerde flag benzeri string gösteriyor, ancak bunların tamamı dikkat dağıtmak için bırakılmış sahte değerler.

Hedef

kepler10b.apk içinden gerçek flag’i çıkarmak.

Kısa Özet

Uygulamadaki akış şu şekilde:

1. Manifest, Java kodu ve native kütüphaneler inceleniyor.
2. Birden fazla sahte flag tespit ediliyor.
3. LoginActivity içindeki giriş kontrolü analiz ediliyor.
4. Native verify fonksiyonundan doğru parola çıkarılıyor.
5. FlagActivity içinde gerçek flag’in dinamik olarak üretildiği anlaşılıyor.

Sahte Flag’ler

Statik analiz sırasında görülen ama gerçek olmayan çıktılar:

• AndroidManifest.xml içindeki FLAG{check_the_manifest_next_time}
• native .so içindeki FLAG{g00d_try_keep_d1gg1ng}
• LoginActivity içindeki FLAG{static_analysis_not_enough}

Bu değerlerin ortak noktası, uygulamanın gerçek akışı tamamlanmadan erişilebilir olmaları. Yani challenge özellikle yüzeysel statik analizi yanıltmak için bu string’leri bırakmış.

Adım Adım Çözüm

1. APK’yı açma ve giriş akışını inceleme

APK jadx ile açıldığında LoginActivity içinde şu mantık görülüyor:

• kullanıcı adı admin olmalı
• parola kontrolü NativeLib.verify(password) ile yapılıyor

Yani Java tarafı yalnızca akışı yönetiyor; gerçek parola doğrulaması native koda bırakılmış.

2. Native verify fonksiyonundan doğru parolayı çıkarma

Native kütüphane analiz edildiğinde verify fonksiyonunun beklediği doğru parola şu olarak bulunuyor:

_wr0ngp4ssw0rd_

Bu değerin bulunmasıyla giriş aşaması geçilebiliyor ve uygulamanın ikinci kısmı aktif oluyor.

3. FlagActivity içindeki gerçek üretim zincirini çözme

Gerçek flag, uygulama içinde düz metin olarak tutulmuyor. FlagActivity tarafındaki akış özetle şöyle:

1. res/raw/seed okunuyor
2. native getKeyMaterial() çağrılıyor
3. bu iki veri XOR’lanıyor
4. elde edilen ara çıktı assets/vault.enc ile tekrar XOR’lanıyor
5. ortaya çıkan sonuç ekrana yazılıyor

Mantık şu şekilde özetlenebilir:

mix = keyMaterial XOR seed
flag = vault.enc XOR mix

4. XOR katmanlarını çözme

Challenge içinde kullanılan iki ara veri:

seed        = aa bb cc dd 11 22 33 44 55 66 77 88 99 aa bb cc
keyMaterial = e4 de b9 af 70 4e 78 21 2c 57 44 bb ae 8b 84 ed

Bu iki blok XOR’landığında mix elde ediliyor. Ardından vault.enc ile tekrar XOR uygulanınca gerçek flag çıkıyor.

Sonuç

Bu challenge’ın ana fikri, statik analiz sırasında görülen ilk string’lere güvenmemekti. Gerçek çıktı ancak doğru native parola bulununca ve FlagActivity içindeki XOR zinciri çözüldüğünde elde edilebiliyor.

Nihai flag: FLAG{R4C0NF_2026_M0B1L3_C0MPL3T3D}

---

04 — Orbital Communications

Çözüm; dosya sistemi analizi, silinmiş artefaktların file carving ile kurtarılması, parola korumalı arşivin açılması ve ses sinyalinin Morse benzeri bir yapıda çözülmesi adımlarından oluşuyor.

Hedef

the_last_orbit.dd imajı içindeki kritik mesajı çıkarmak.

Kısa Özet

İzlenen zincir şu şekildeydi:

1. Disk imajının GPT ve NTFS yapısı doğrulandı.
2. Dosya ağacı çıkarıldı ve önemli artefaktlar belirlendi.
3. Loglar ile tarayıcı verilerinden parola ipuçları toplandı.
4. Ham disk üzerinde silinmiş Chrome login verisi bulundu.
5. Kurtarılan parola ile orbital_backup arşivi açıldı.
6. Arşivden çıkan signal.wav dosyası çözüldü.
7. Ses sinyalinden RACONF.COM/4815162342 mesajı elde edildi.

Adım Adım Çözüm

1. İmajın yapısını doğrulama

İlk adımda imajın türü ve bölüm yapısı kontrol edildi:

file the_last_orbit.dd
ls -lh the_last_orbit.dd
shasum -a 256 the_last_orbit.dd
gpt -r show the_last_orbit.dd

Çıkan temel bilgiler:

• dosya ham disk imajı
• boyut yaklaşık 50 MiB
• GPT bölüm tablosu var
• tek bir temel veri bölümü bulunuyor
• bölüm başlangıcı sektör 128, yani byte ofseti 65536

2. Dosya sistemini tanımlama

Bölüm başlangıcındaki boot sector kontrol edildi:

dd if=the_last_orbit.dd bs=512 skip=128 count=8 2>/dev/null | xxd

Burada NTFS imzası görüldü. Yani imajın içindeki ana bölüm NTFS 3.1.

3. Dosya ağacını çıkarma

Sistemde klasik adli araçlar bulunmadığı için içerik 7z ile listelendi:

7z l the_last_orbit.dd

Bu yöntemle öne çıkan dosyalar tespit edildi:

• Downloads/orbital_backup
• Downloads/signal.mp3
• Logs/slack_export_1310.log
• Users/orbital/Local/Google/Chrome/User Data/Default/logins.json

4. Metin tabanlı artefaktlardan bağlam toplama

Küçük dosyalar doğrudan stdout’a çıkarılarak incelendi:

7z x -so /tmp/the_last_orbit_extract/basic_data_partition.img "Logs/slack_export_1310.log"
7z x -so /tmp/the_last_orbit_extract/basic_data_partition.img "Users/orbital/Local/Google/Chrome/User Data/Default/logins.json"

Öne çıkan:

• Slack log’larında Kate’in bir parolayı farklı yerlerde tekrar kullandığına dair ipucu var.
• logins.json içinde parola benzeri bir değer bulunuyor.
• Ancak aktif dosyalardaki bu değer orbital_backup arşivini açmıyor.

Yani çözüm, sadece mevcut dosyalardaki veriden değil, silinmiş kalıntılardan geliyor.

5. Ham disk üzerinde silinmiş login verisi arama

İmajın tamamında string ve imza taraması yapıldı:

strings -n 4 the_last_orbit.dd | rg -i "orbital-intranet|encryptedPassword|Login Data|SQLite format|password TEXT|raccoon_master"
rg -a -b "orbital-intranet.local|encryptedPassword|origin_url TEXT" the_last_orbit.dd

Bu taramalar iki önemli bulgu verdi:

1. Disk üzerinde SQLite format 3 başlığı olan bir veritabanı kalıntısı vardı.
2. Login Data isimli silinmiş Chrome artefaktına ait izler bulunuyordu.

6. Silinmiş SQLite veritabanını file carving ile kurtarma

Bulunan ofsetten küçük bir parça alınıp SQLite olarak açıldı:

dd if=the_last_orbit.dd of=/tmp/the_last_orbit_extract/recovered_logins.sqlite bs=1 skip=9232384 count=102400
file /tmp/the_last_orbit_extract/recovered_logins.sqlite
sqlite3 /tmp/the_last_orbit_extract/recovered_logins.sqlite '.tables'
sqlite3 /tmp/the_last_orbit_extract/recovered_logins.sqlite 'select * from logins;'

logins tablosundaki asıl kayıt:

http://orbital-reactor-login.local|admin_orbital|Q-K3y_0rb1t@l_77x$!

Bu, aktif dosyalarda görünmeyen ama silinmiş veriden kurtarılan gerçek parolaydı.

7. Arşiv parolasını doğrulama

Önce arşiv dosyası ayrı ZIP olarak çıkarıldı:

7z x -so /tmp/the_last_orbit_extract/basic_data_partition.img "Downloads/orbital_backup" > /tmp/the_last_orbit_extract/orbital_backup.zip

Ardından kurtarılan parolalar test edildi:

sqlite3 /tmp/the_last_orbit_extract/recovered_logins.sqlite 'select password from logins' | while read p; do
  printf '%s -> ' "$p"
  7z t -p"$p" /tmp/the_last_orbit_extract/orbital_backup.zip >/dev/null 2>&1 && echo OK && break || echo NO
done

Doğru parola: Q-K3y_0rb1t@l_77x$!

8. Arşivden signal.wav dosyasını çıkarma

7z x -y -p'Q-K3y_0rb1t@l_77x$!' /tmp/the_last_orbit_extract/orbital_backup.zip -o/tmp/the_last_orbit_extract/orbital_backup_files
afinfo /tmp/the_last_orbit_extract/orbital_backup_files/signal.wav

Dosya özellikleri:

• WAVE, 8-bit unsigned PCM, mono, 8000 Hz
• yaklaşık 18.56 saniye

Konuşma kaydı gibi değil, düzenli tonlardan oluşan bir sinyal yapısı.

9. Ses sinyalini çözme

Ham veri ve kısa FFT incelemesi sonrasında:

• baskın frekans yaklaşık 550 Hz
• bilgi frekansta değil, genlikte taşınıyor
• açık/kapalı süreler 1 birim ve 3 birim oranında → Morse benzeri kodlama

Ham sembol çıktısı:

.-. .- -.-. --- -. ..-. .-.-.- -.-. --- -- -..-. ....- ---.. .---- ..... .---- -.... ..--- ...-- ....- ..---

Burada .-.-.- = . ve -..-. = / olarak çözüldü.

Sonuç

Bu challenge’da asıl kilit nokta, aktif dosyalarla yetinmeyip ham disk üzerinde silinmiş artefakt aramaktı.

Q-K3y_0rb1t@l_77x$!   -> arşiv parolası
RACONF.COM/4815162342  -> ses kaydından çıkan mesaj

---

05 — Helix Biocore

Çözüm; zayıf RSA anahtarının faktörlenmesi, RSA ile sarılmış AES anahtarının çözülmesi ve ardından AES-CBC ile asıl içeriğin açılması adımlarından oluşuyor.

Hedef

biocore_packet.json içindeki gerçek flag’i elde etmek.

Kısa Özet

Paket hibrit kripto yapısında hazırlanmış:

• AES anahtarı RSA ile sarılmış
• asıl veri AES ile şifrelenmiş
• verilen RSA public key yalnızca 512-bit, yani pratikte kırılabilir

Doğru yaklaşım:

1. Public key’den n ve e değerlerini çıkarmak
2. n değerini faktörleyip private key’i yeniden kurmak
3. RSA ile sarılmış AES anahtarını çözmek
4. Çıkan AES anahtarıyla son veriyi decrypt etmek

Paket Yapısı

Verilen JSON şu üç alanı içeriyor:

{
  "encrypted_aes_key": "X06IwOX5ivBOEm5/0I3uz3mxn++9Me68hNiK+7/5/Srodh1vfE/HSvxyu96KEVl3eZ8Z7+lFkx4g7G6BINeM3Q==",
  "iv": "5l2jLBzRe2SSCFfx8aAJcg==",
  "genome_sequence": "gB0kPlM1VOQpv9nbuktyLg=="
}

Adım Adım Çözüm

1. RSA modulus’u faktörleme

Public key’den çıkan modulus 512-bit. Faktörler:

p = 80988589455501896011739178268999336156860010652732643480830847714524041407079
q = 110897562622294808004783687269172110140112354020217622832576188018309973983661

Sonrasında phi = (p-1)*(q-1) ve d = e^-1 mod phi ile private exponent hesaplanıyor.

2. Sarılmış AES anahtarını çözme

encrypted_aes_key alanı PKCS#1 v1.5 padding ile sarılmış. RSA decrypt sonrası çıkan mesaj base64 decode edildiğinde gerçek AES anahtarı:

61f4eeaa16174ec3738e32c4e9a16478

3. AES-CBC ile son veriyi çözme

• AES key = 61f4eeaa16174ec3738e32c4e9a16478
• IV = e65da32c1cd17b64920857f1f1a00972
• Ciphertext = 801d243e533554e429bfd9dbba4b722e

AES-CBC decrypt + PKCS#7 padding temizleme → gerçek flag.

Python Çözümü

import json, base64
from Crypto.PublicKey import RSA
from Crypto.Cipher import PKCS1_v1_5, AES
from Crypto.Util.number import inverse
from Crypto.Util.Padding import unpad

p = 80988589455501896011739178268999336156860010652732643480830847714524041407079
q = 110897562622294808004783687269172110140112354020217622832576188018309973983661
e = 65537
n = p * q
d = inverse(e, (p-1)*(q-1))
priv = RSA.construct((n, e, d, p, q))

with open("biocore_packet.json") as f:
    packet = json.load(f)

wrapped = base64.b64decode(packet["encrypted_aes_key"])
iv      = base64.b64decode(packet["iv"])
ct      = base64.b64decode(packet["genome_sequence"])

msg     = PKCS1_v1_5.new(priv).decrypt(wrapped, b"BAD")
aes_key = base64.b64decode(msg)
flag    = unpad(AES.new(aes_key, AES.MODE_CBC, iv).decrypt(ct), 16)
print(flag.decode())

Sonuç

Zayıf halka 512-bit RSA kullanılmasıydı. Private key yeniden kurulduktan sonra kalan kısım standart bir hibrit kripto çözümüne dönüyor.

Nihai flag: RKN{1vcl9zYWN}

---

06 — Quante Systems

Çözüm temel olarak üç binary’nin birlikte okunmasına dayanıyor: biri XOR çekirdeğini, biri karakter dizilim mantığını, sonuncusu ise gerçek doğrulama akışını veriyor.

Hedef

Doğru giriş anahtarını ve ardından gerçek flag’i elde etmek.

Kısa Özet

Challenge boyunca görülen dosyaların rolleri farklı:

• quantex_audit.bin: yanıltıcı ama XOR çekirdeğini ele veriyor
• quantex_backup.bin: characterlere uygulanan permutation mantığını gösteriyor
• quantex_guard.bin: son doğrulama modülü ve gerçek karşılaştırma burada yapılıyor

Doğru yaklaşım bu üç parçayı birlikte okuyup dönüşümü tersine çevirmek.

Adım Adım Çözüm

1. İlk ipuçlarını toplama

dead_drop_01.txt ve incident_report.log, doğrulama zincirinin tek bir binary içinde olmadığını söylüyor. Yani sadece bir dosyaya bakmak eksik sonuç verecek.

2. XOR çekirdeğini çıkarma

quantex_guard.bin içindeki giriş işleme akışı incelendiğinde, kullanıcı girdisine önce 3 baytlık tekrar eden bir XOR uygulandığı görülüyor:

13 37 42

Yani giriş baytları sırasıyla şu döngüyle maskeleniyor:

input[i] ^ key[i % 3]

3. Permutation adımını bulma

quantex_backup.bin, doğrulamanın yalnızca XOR ile yapılmadığını gösteriyor. XOR sonrası elde edilen veriye şu index sırasıyla permutation uygulanıyor:

[2, 0, 4, 1, 3, 6, 5, 8, 7, 9, 10, 11, 12]

Bu, son karşılaştırmanın doğrudan kullanıcı girdisi üzerinde değil; önce XOR ardından permutation uygulanmış veri üzerinde gerçekleştiği anlamına geliyor.

4. Guard modülündeki son kontrolü tersine çevirme

quantex_guard.bin içinde:

1. girişe XOR uygulanıyor
2. çıktı yeniden sıralanıyor
3. ortaya çıkan 13 bayt, binary içindeki hedef diziyle karşılaştırılıyor
4. ayrıca checksum doğrulaması yapılıyor

Bu işlemler tersine çevrildiğinde beklenen doğru giriş anahtarı: s4Us1B3R4Ev3r

Flag’in Üretilmesi

Doğru giriş bulunduğunda quantex_guard.bin içindeki .data bölümünde şu 16 bayt saklanıyor:

78 61 64 51 60 1b 48 6c 13 42 48 47 6c 45 4e 57

Bu veri 0x2a ile XORlandığında gerçek çıktı ortaya çıkıyor.

Sonuç

Bu challenge’ın püf noktası, modülleri izole değil zincir halinde okumaktı.

Doğru giriş anahtarı: s4Us1B3R4Ev3r

Nihai flag: RKN{J1bF9hbmFod}