[Writeup] Password or Payload? – Keyboard-Only Shellcode Analizi

drag4n · 7 Ocak 2026

Challenge:

koboldschwaengel's Password or Payload?

I guess there ist only one way to find the answer. Have fun!

crackmes.one

İyi günler, iyi akşamlar. Dün karşıma çıkan güzel bir shellcode mantığı içeren "Password or Payload" challenge'ını inceleyeceğiz. Program bizden bir şifre istiyor ama author'un bahsettiği üzere "Input injector yok, sadece klavye serbest" demiş. Yani elimizdeki kısıtlı karakter setiyle (printable ASCII) programın akışını yönlendirmemiz lazım. Klasik bir "şifreyi bul" sorusu değil, daha çok "geçerli bir kod yaz ve çalıştır" sorusu.

1. Recon

Binary'yi IDA Pro ile açarak analize başlıyoruz. İlk olarak programın yapısını anlamak için Strings penceresini kontrol ediyoruz. Burada, programın çalışma zamanında kullanıcıya gösterdiği "Enter the Password:", "pass is correct!" ve "passwort is incorrect" gibi geri bildirim mesajları açıkça görülüyor.

Bu mesajlar, ilk bakışta programın standart bir "şifre doğrulama" işlemi yapacağı izlenimini veriyor. Ancak bu varsayımı doğrulamadan önce programın hangi API'leri kullandığına bakmamız şart.

Import Table'ı incelediğimizde dikkat çekici bir detayla karşılaşıyoruz:

Program, VirtualAlloc fonksiyonunu import ediyor. Basit bir metin karşılaştırma programının, Windows'tan manuel olarak bellek tahsis etmesi (memory allocation) olağan bir durum değil. Bu API genellikle dinamik kod çalıştırma veya unpacking işlemlerinde kullanılır. Bu aşamada, programın basit bir crackme'den fazlası olabileceğine dair ilk ipucumuzu alıyoruz.

2. Derin Analiz: Code Execution Mantığı

Şüphelerimizi doğrulamak için main fonksiyonunu inceliyoruz. Kod akışının, standart bir karşılaştırma (if password == input) algoritmasından çok farklı olduğunu görüyoruz.

A. Input Alımı ve Bellek Tahsisi

Önce fgets ile bizden input alınıyor.

Hemen ardından VirtualAlloc çağrılıyor. Burada en kritik detay r9d register'ına atanan değerdir.

"mov r9d, 40h" Bu 0x40 değeri, Windows API'sinde PAGE_EXECUTE_READWRITE iznine denk gelir. Yani bu bellek alanı, içine veri yazıp kod çalıştırabileceğimiz özel bir alandır.

B. Shellcode Çalıştırma ve Karar Mekanizması

Program, bizim input'umuzu RWX belleğe kopyaladıktan sonra onu kod olarak çalıştırıyor. Aşağıdaki grafikte bu akışı net görebilirsiniz:

Grafiği adım adım inceleyelim:

call rdi	rdi register'ında tutulan adrese (bizim input'umuzun kopyalandığı RWX bellek) dallan ve oradaki kodu çalıştır.
test al, al	Çalıştırılan kodun dönüş değerini (AL register) kontrol et. AL, RAX'ın alt 8 bit'idir.
lea rcx, "pass is correct!"	Önce success string'ini RCX'e yükle (puts için hazırlık).
jnz short loc_140001125	Eğer AL ≠ 0 ise puts'a (loc_140001125) atla ve "pass is correct!" yazdır.
lea rcx, "passwort is incorrect"	Eğer AL = 0 ise bu satıra düşer ve fail string'i yüklenir.

Özetle program bizden şunu istiyor. "Bana öyle karakterler ver ki, ben bunları makine kodu (opcode) olarak çalıştırdığımda, bana 0 olmayan bir sonuç (return value) ile geri dön."

3. Keyboard-Only Shellcode

Normal şartlarda, bir fonksiyondan 1 (true) döndürmek için Assembly'de şu basit iki satırı yazarız:

mov al, 1	AL = 1
ret	Return

Bu kodun makine dili karşılığı: B0 01 C3.

Fakat daha önce bahsettiğim üzere. Sadece klavye kullanabiliriz. B0 (mov al) byte'ı, standart ASCII tablosunda basılabilir bir karaktere denk gelmiyor. Hex editör kullanamadığımız için, sadece klavyedeki harflerle aynı işi yapan alternatif bir opcode zinciri kurmamız gerekiyor.

Çözüm Matrisi

Hedefimiz yukarıda bahsettiğimiz AL register'ını 0 dışı bir değer yapmak ve ret ile çıkmak.

ADIM 1: push 0x31

Opcode	6A 31
Klavye	j1
Ne yapıyor?	0x6A (push imm8) komutu j harfine denk gelir. Arkasındaki 0x31 ise 1 karakteri. Stack'e 0x31 (decimal 49) değerini atıyoruz.

ADIM 2: pop rax

Opcode	58
Klavye	X
Ne yapıyor?	Stack'teki 0x31 değerini RAX register'ına çekiyoruz. RAX'ın alt 8 bit'i AL olduğu için artık AL = 0x31 (sıfır değil!).

ADIM 3: ret

Opcode	C3
Klavye	À (Alt+0192 veya kopyala-yapıştır)
Ne yapıyor?	İşin zor kısmı burası.... Program UTF-8 modunda çalışıyor (SetConsoleCP(65001)). À karakteri UTF-8'de C3 80 olarak kodlanır. İlk byte C3 = ret komutu, fonksiyondan çıkıyoruz. İkinci byte (80) ise ret'ten sonra geldiği için CPU buraya hiç ulaşmıyor yani önemsiz.

4. Payload ve Sonuç

Final payload'ımız şu 4 karakterden oluşuyor: j1XÀ

Gördüğünüz üzere payloadımız çalıştı. Eğer buraya kadar okuduysanız ve aklınızda herhangi bir soru varsa sorabilirsiniz.

Not: Bunu çözerken bir kaç kaynaktan yardım almıştım ayrıca. Göz atmak isteyen varsa onları da ekliyorum.

Shellcode ve Process Injection

Windows Process Injection Fundamentals — VirtualAlloc, WriteProcessMemory ve shellcode çalıştırma temelleri.
Loading and Executing Shellcode From PE Resources (ired.team) — Visual Studio ile shellcode yükleme ve çalıştırma.
What is Process Injection? Techniques & Preventions (SentinelOne) — Process injection tekniklerine genel bakış.

x86-64 Opcode Referansları

X86 Opcode and Instruction Reference (coder64) — 64-bit opcode tablosu, her instruction'ın byte karşılıkları.
Intel x86 Opcode Table (shell-storm) — Kapsamlı Intel opcode referansı.
Stanford CS107 x86-64 Reference Sheet (PDF) — Hızlı başvuru için özet tablo.

Alphanumeric / Printable Shellcode

Alphanumeric Shellcode (Offensive Security) — Metasploit ile alphanumeric shellcode üretimi.
ASCII Shellcode (NetSec) — Printable karakter kısıtlamalarıyla shellcode yazma.
Linux Alphanumeric Shellcode — Sadece alfanumerik karakterlerle execve() shellcode.

UTF-8 ve Unicode Shellcode

UTF-8 Shellcode (Phrack #62) — UTF-8 encoding ile shellcode bypass teknikleri. (Klasik makale)
Writing Unicode Payloads (Venetian Shellcode) — Unicode kullanan uygulamalarda exploit geliştirme.

an0un · 7 Ocak 2026

Gayet güzel bir anlatım olmuş çok detaylı inceleyemedim fakat güzel duruyor, ellerinize emeklerinize sağık.

drag4n · 7 Ocak 2026

an0un' Alıntı:
Gayet güzel bir anlatım olmuş çok detaylı inceleyemedim fakat güzel duruyor, ellerinize emeklerinize sağık.

Rica ederim teşekkürler : = )

Napcaz · 8 Ocak 2026

Soru ilgimi çekti bende biraz analiz yaptım konu altında paylaşmak isterim. Soru aslında görünenden daha ince tasarlanmış. İlk fark ettiğim sorunun readme sinde yazan şu ipucu:
Hint 2:
dont except a loss when using the debugger

Debugger la alakalı bazı meselelerimiz var yani.
Soru da senin bahsettiğin kısım çalışmadan önce yapılan bazı debugger dan kaçınma ve debugger tespit etme aksiyonları var.

Burası senin bahsettiğin bizim input umuzun rdi de olduğu ve çalıştırıldığı kısım
Biraz yukarda ise çok tatlı bir ayak oyunu var.

Bahsetmek istediğim yer burası. VirtualAlloc ile 32byte lık bir yer allocate ettikten sonra bu yere yeşil okla gösterdiğim yerde 0xff, 0x25 olan iki byte yükleniyor bu byte lar jmp qword ptr [rip+0x0] instruction una tekabül ediyor ve bir sonraki adresteki veriye zıplanmaya çalışıyor ama bir sonraki adres de allocte edilen bölgede olduğu ve bu bölgeye 0xff 0x25 dışında bir şey yazmadığımız için sıfırla dolu. O yüzden 0 adresine jmp etmeye çalışyoruz ki bu adrese user-space den erişme iznimiz olmadığı için exception fırlıyor.

Crackme yi geliştiren kişi buraya bir try except bloğu yerleştirmiş ida da bunu gösteriyor yukardaki resimde sarı şeritli yere bakarsanız try bloğunda hata olunca zıplanan loc_140001097 tag lı except block u görebilirsiniz. IDA bunu bize göstermesede bulabiliriz bunun için. Microsoft un try except bloklarını nasıl işlediği ve kontrol ettiği konusunda fikir sahibi olmak gerekiyor ki benim bu konuda çok az bilgim var konuyu araştırırken bir kaç makaleyi okumaya çalıştım:

Abusing Exceptions for Code Execution, Part 2

In this article, we'll explore how the concepts behind Exception Oriented Programming can be abused when exploiting stack overflow vulnerabilities on Windows.

billdemirkapi.me

Boots for Walking Backwards: Teaching pefile How to Understand SEH-Related Data in 64-bit PE Files

Explains how SEH-related data is stored in 64-bit PE+ files and used by Windows to perform stack unwinding and documents the process of implementing an extension to pefile that would read relevant sections of PE+ images.

auscitte.github.io

Az buçuk anladığım kadarıyla PE file ın exception directory sine bakılarak hangi adres aralıklarına hangi exception handler ların tanımlandığını görebileceğimizi fark ettim. Eğer crackme nin exception directory sine bakarsak tam da main fonksiyon için bir exception handler tanımlandığını görebiliriz.

RUNTIME_FUNCTION struct u bu şekilde tanımlanıyor:

C:

typedef struct _RUNTIME_FUNCTION {
    ULONG BeginAddress;
    ULONG EndAddress;
    ULONG UnwindData;
} RUNTIME_FUNCTION, *PRUNTIME_FUNCTION;

BeginAddress main fonksiyonun başını gösteriyor EndAddress de sonunu. UnwindData da exception ile ilgili bilgiler. Hadi ona bakalım.

C:

typedef struct _UNWIND_INFO {
    UBYTE Version       : 3;
    UBYTE Flags         : 5;
    UBYTE SizeOfProlog;
    UBYTE CountOfCodes;
    UBYTE FrameRegister : 4;
    UBYTE FrameOffset   : 4;
    UNWIND_CODE UnwindCode[1];
/*  UNWIND_CODE MoreUnwindCode[((CountOfCodes + 1) & ~1) - 1];
*   union {
*       OPTIONAL ULONG ExceptionHandler;
*       OPTIONAL ULONG FunctionEntry;
*   };
*   OPTIONAL ULONG ExceptionData[]; */
} UNWIND_INFO, *PUNWIND_INFO;

Burası çok karışık açıkçası benim için ama IDA dan bakınca bir tık daha anlaşılır geliyor.

__GSHAndlerCheck_SEH Microsoft un genel olarak exception ları handle etmek için kullandığı bir fonksiyon built-in derleme esnasında koda ekleniyor. Ona verilen parametreler arasından DispatcherContext de Scope Table denilen şeyde bulunuyor bu table bizim spesifik olarak main fonksiyonu içerisinde hangi adres aralıklarında hangi adres e atlayacağımızı exception handler ımza anlatmak için var. Tanımı şu şekilde:

C:

typedef struct _SCOPE_TABLE {
    ULONG Count;   // ScopeRecord sayısı
    struct {
        ULONG BeginAddress;    // RVA
        ULONG EndAddress;      // RVA
        ULONG HandlerAddress;  // RVA (filter veya finally)
        ULONG JumpTarget;      // RVA (except body veya 0)
    } ScopeRecord[1];
} SCOPE_TABLE;

IDA da gördüğünüz üzere 2 adet entry miz var ve bu iki entry de kodda iki farklı exception bloğunu ifade etmek için var ilki benim gösterdiğim yer. Burda yukarda da açıkladığım üzere kasıtlı bir exception oluşturuluyor ve bu exception sonucu loc_140001097 bloğuna gidiyoruz bu blok IsDebuggerPresent API si ile Process e debugger attach edilmiş mi kontrol ediyor crackme eğer edildiyse girdimizin ilk 2 byte ı yukardaki resimde kırmızı okla gösterdiğim yerde bozuluyor böylece payload ımız hiç çalışamaz hale getirilmiş oluyor. Bu ince kısım çok hoşuma gitti crackme yi test ederken sizin payload bir türlü çalışmayınca nedenini araştırıp fark ettim bahsetmek istedim.

Ekstra olarak scope table daki ikinci entry de bizim payload umuzu çalıştıran esas yer yani sizin konunuzda detaylıca bahsettiğiniz kısım. Eğer payload düzgün çalıştırılamazsa loc_14000112D bloğuna zıplanıyor ki orası da "passwort is incorrect" mesajını oluşturuyor. Eğer payload düzgün çalışırsa bu exception tetiklenmiyor ama bu seferde eax register ının düşük 8bit ine bakılıyor 0 değilse başarılı öteki türlü gene incorrect mesajı.

drag4n · 8 Ocak 2026

Napcaz' Alıntı:
Soru ilgimi çekti bende biraz analiz yaptım konu altında paylaşmak isterim. Soru aslında görünenden daha ince tasarlanmış. İlk fark ettiğim sorunun readme sinde yazan şu ipucu:
Hint 2:
dont except a loss when using the debugger

Debugger la alakalı bazı meselelerimiz var yani.
Soru da senin bahsettiğin kısım çalışmadan önce yapılan bazı debugger dan kaçınma ve debugger tespit etme aksiyonları var.

Burası senin bahsettiğin bizim input umuzun rdi de olduğu ve çalıştırıldığı kısım
Biraz yukarda ise çok tatlı bir ayak oyunu var.

Bahsetmek istediğim yer burası. VirtualAlloc ile 32byte lık bir yer allocate ettikten sonra bu yere yeşil okla gösterdiğim yerde 0xff, 0x25 olan iki byte yükleniyor bu byte lar jmp qword ptr [rip+0x0] instruction una tekabül ediyor ve bir sonraki adresteki veriye zıplanmaya çalışıyor ama bir sonraki adres de allocte edilen bölgede olduğu ve bu bölgeye 0xff 0x25 dışında bir şey yazmadığımız için sıfırla dolu. O yüzden 0 adresine jmp etmeye çalışyoruz ki bu adrese user-space den erişme iznimiz olmadığı için exception fırlıyor.

Crackme yi geliştiren kişi buraya bir try except bloğu yerleştirmiş ida da bunu gösteriyor yukardaki resimde sarı şeritli yere bakarsanız try bloğunda hata olunca zıplanan loc_140001097 tag lı except block u görebilirsiniz. IDA bunu bize göstermesede bulabiliriz bunun için. Microsoft un try except bloklarını nasıl işlediği ve kontrol ettiği konusunda fikir sahibi olmak gerekiyor ki benim bu konuda çok az bilgim var konuyu araştırırken bir kaç makaleyi okumaya çalıştım:

Abusing Exceptions for Code Execution, Part 2

In this article, we'll explore how the concepts behind Exception Oriented Programming can be abused when exploiting stack overflow vulnerabilities on Windows.

billdemirkapi.me

Boots for Walking Backwards: Teaching pefile How to Understand SEH-Related Data in 64-bit PE Files

Explains how SEH-related data is stored in 64-bit PE+ files and used by Windows to perform stack unwinding and documents the process of implementing an extension to pefile that would read relevant sections of PE+ images.

auscitte.github.io

Az buçuk anladığım kadarıyla PE file ın exception directory sine bakılarak hangi adres aralıklarına hangi exception handler ların tanımlandığını görebileceğimizi fark ettim. Eğer crackme nin exception directory sine bakarsak tam da main fonksiyon için bir exception handler tanımlandığını görebiliriz.

RUNTIME_FUNCTION struct u bu şekilde tanımlanıyor:

C:

typedef struct _RUNTIME_FUNCTION { ULONG BeginAddress; ULONG EndAddress; ULONG UnwindData; } RUNTIME_FUNCTION, *PRUNTIME_FUNCTION;

BeginAddress main fonksiyonun başını gösteriyor EndAddress de sonunu. UnwindData da exception ile ilgili bilgiler. Hadi ona bakalım.

C:

typedef struct _UNWIND_INFO { UBYTE Version : 3; UBYTE Flags : 5; UBYTE SizeOfProlog; UBYTE CountOfCodes; UBYTE FrameRegister : 4; UBYTE FrameOffset : 4; UNWIND_CODE UnwindCode[1]; /* UNWIND_CODE MoreUnwindCode[((CountOfCodes + 1) & ~1) - 1]; * union { * OPTIONAL ULONG ExceptionHandler; * OPTIONAL ULONG FunctionEntry; * }; * OPTIONAL ULONG ExceptionData[]; */ } UNWIND_INFO, *PUNWIND_INFO;

Burası çok karışık açıkçası benim için ama IDA dan bakınca bir tık daha anlaşılır geliyor.

__GSHAndlerCheck_SEH Microsoft un genel olarak exception ları handle etmek için kullandığı bir fonksiyon built-in derleme esnasında koda ekleniyor. Ona verilen parametreler arasından DispatcherContext de Scope Table denilen şeyde bulunuyor bu table bizim spesifik olarak main fonksiyonu içerisinde hangi adres aralıklarında hangi adres e atlayacağımızı exception handler ımza anlatmak için var. Tanımı şu şekilde:

C:

typedef struct _SCOPE_TABLE { ULONG Count; // ScopeRecord sayısı struct { ULONG BeginAddress; // RVA ULONG EndAddress; // RVA ULONG HandlerAddress; // RVA (filter veya finally) ULONG JumpTarget; // RVA (except body veya 0) } ScopeRecord[1]; } SCOPE_TABLE;

IDA da gördüğünüz üzere 2 adet entry miz var ve bu iki entry de kodda iki farklı exception bloğunu ifade etmek için var ilki benim gösterdiğim yer. Burda yukarda da açıkladığım üzere kasıtlı bir exception oluşturuluyor ve bu exception sonucu loc_140001097 bloğuna gidiyoruz bu blok IsDebuggerPresent API si ile Process e debugger attach edilmiş mi kontrol ediyor crackme eğer edildiyse girdimizin ilk 2 byte ı yukardaki resimde kırmızı okla gösterdiğim yerde bozuluyor böylece payload ımız hiç çalışamaz hale getirilmiş oluyor. Bu ince kısım çok hoşuma gitti crackme yi test ederken sizin payload bir türlü çalışmayınca nedenini araştırıp fark ettim bahsetmek istedim.

Ekstra olarak scope table daki ikinci entry de bizim payload umuzu çalıştıran esas yer yani sizin konunuzda detaylıca bahsettiğiniz kısım. Eğer payload düzgün çalıştırılamazsa loc_14000112D bloğuna zıplanıyor ki orası da "passwort is incorrect" mesajını oluşturuyor. Eğer payload düzgün çalışırsa bu exception tetiklenmiyor ama bu seferde eax register ının düşük 8bit ine bakılıyor 0 değilse başarılı öteki türlü gene incorrect mesajı.

Ek bilgiler için tekrar teşekkürler elinize sağlık

aga67 · 9 Ocak 2026

Napcaz' Alıntı:
Soru ilgimi çekti bende biraz analiz yaptım konu altında paylaşmak isterim. Soru aslında görünenden daha ince tasarlanmış. İlk fark ettiğim sorunun readme sinde yazan şu ipucu:
Hint 2:
dont except a loss when using the debugger

Debugger la alakalı bazı meselelerimiz var yani.
Soru da senin bahsettiğin kısım çalışmadan önce yapılan bazı debugger dan kaçınma ve debugger tespit etme aksiyonları var.

Burası senin bahsettiğin bizim input umuzun rdi de olduğu ve çalıştırıldığı kısım
Biraz yukarda ise çok tatlı bir ayak oyunu var.

Bahsetmek istediğim yer burası. VirtualAlloc ile 32byte lık bir yer allocate ettikten sonra bu yere yeşil okla gösterdiğim yerde 0xff, 0x25 olan iki byte yükleniyor bu byte lar jmp qword ptr [rip+0x0] instruction una tekabül ediyor ve bir sonraki adresteki veriye zıplanmaya çalışıyor ama bir sonraki adres de allocte edilen bölgede olduğu ve bu bölgeye 0xff 0x25 dışında bir şey yazmadığımız için sıfırla dolu. O yüzden 0 adresine jmp etmeye çalışyoruz ki bu adrese user-space den erişme iznimiz olmadığı için exception fırlıyor.

Crackme yi geliştiren kişi buraya bir try except bloğu yerleştirmiş ida da bunu gösteriyor yukardaki resimde sarı şeritli yere bakarsanız try bloğunda hata olunca zıplanan loc_140001097 tag lı except block u görebilirsiniz. IDA bunu bize göstermesede bulabiliriz bunun için. Microsoft un try except bloklarını nasıl işlediği ve kontrol ettiği konusunda fikir sahibi olmak gerekiyor ki benim bu konuda çok az bilgim var konuyu araştırırken bir kaç makaleyi okumaya çalıştım:

Abusing Exceptions for Code Execution, Part 2

In this article, we'll explore how the concepts behind Exception Oriented Programming can be abused when exploiting stack overflow vulnerabilities on Windows.

billdemirkapi.me

Boots for Walking Backwards: Teaching pefile How to Understand SEH-Related Data in 64-bit PE Files

Explains how SEH-related data is stored in 64-bit PE+ files and used by Windows to perform stack unwinding and documents the process of implementing an extension to pefile that would read relevant sections of PE+ images.

auscitte.github.io

Az buçuk anladığım kadarıyla PE file ın exception directory sine bakılarak hangi adres aralıklarına hangi exception handler ların tanımlandığını görebileceğimizi fark ettim. Eğer crackme nin exception directory sine bakarsak tam da main fonksiyon için bir exception handler tanımlandığını görebiliriz.

RUNTIME_FUNCTION struct u bu şekilde tanımlanıyor:

C:

typedef struct _RUNTIME_FUNCTION { ULONG BeginAddress; ULONG EndAddress; ULONG UnwindData; } RUNTIME_FUNCTION, *PRUNTIME_FUNCTION;

BeginAddress main fonksiyonun başını gösteriyor EndAddress de sonunu. UnwindData da exception ile ilgili bilgiler. Hadi ona bakalım.

C:

typedef struct _UNWIND_INFO { UBYTE Version : 3; UBYTE Flags : 5; UBYTE SizeOfProlog; UBYTE CountOfCodes; UBYTE FrameRegister : 4; UBYTE FrameOffset : 4; UNWIND_CODE UnwindCode[1]; /* UNWIND_CODE MoreUnwindCode[((CountOfCodes + 1) & ~1) - 1]; * union { * OPTIONAL ULONG ExceptionHandler; * OPTIONAL ULONG FunctionEntry; * }; * OPTIONAL ULONG ExceptionData[]; */ } UNWIND_INFO, *PUNWIND_INFO;

Burası çok karışık açıkçası benim için ama IDA dan bakınca bir tık daha anlaşılır geliyor.

__GSHAndlerCheck_SEH Microsoft un genel olarak exception ları handle etmek için kullandığı bir fonksiyon built-in derleme esnasında koda ekleniyor. Ona verilen parametreler arasından DispatcherContext de Scope Table denilen şeyde bulunuyor bu table bizim spesifik olarak main fonksiyonu içerisinde hangi adres aralıklarında hangi adres e atlayacağımızı exception handler ımza anlatmak için var. Tanımı şu şekilde:

C:

typedef struct _SCOPE_TABLE { ULONG Count; // ScopeRecord sayısı struct { ULONG BeginAddress; // RVA ULONG EndAddress; // RVA ULONG HandlerAddress; // RVA (filter veya finally) ULONG JumpTarget; // RVA (except body veya 0) } ScopeRecord[1]; } SCOPE_TABLE;

IDA da gördüğünüz üzere 2 adet entry miz var ve bu iki entry de kodda iki farklı exception bloğunu ifade etmek için var ilki benim gösterdiğim yer. Burda yukarda da açıkladığım üzere kasıtlı bir exception oluşturuluyor ve bu exception sonucu loc_140001097 bloğuna gidiyoruz bu blok IsDebuggerPresent API si ile Process e debugger attach edilmiş mi kontrol ediyor crackme eğer edildiyse girdimizin ilk 2 byte ı yukardaki resimde kırmızı okla gösterdiğim yerde bozuluyor böylece payload ımız hiç çalışamaz hale getirilmiş oluyor. Bu ince kısım çok hoşuma gitti crackme yi test ederken sizin payload bir türlü çalışmayınca nedenini araştırıp fark ettim bahsetmek istedim.

Ekstra olarak scope table daki ikinci entry de bizim payload umuzu çalıştıran esas yer yani sizin konunuzda detaylıca bahsettiğiniz kısım. Eğer payload düzgün çalıştırılamazsa loc_14000112D bloğuna zıplanıyor ki orası da "passwort is incorrect" mesajını oluşturuyor. Eğer payload düzgün çalışırsa bu exception tetiklenmiyor ama bu seferde eax register ının düşük 8bit ine bakılıyor 0 değilse başarılı öteki türlü gene incorrect mesajı.

ben de bir sey eklemek istiyorum

parola, stack'teki bir yeri temsil ediyor. shellcodeAlani, kullanicidan alinan karakterlerin kopyalandigi virtual memory alanini temsil ediyor.

sari cizgiyle gosterdigim yerdeki iki kondisyondan biri her zaman calisiyor. "genelde" heap, virtual memory alanlarinin adresi ayrilan stack'ten daha buyuk olur. boyle olmasa dahi ikinci kondisyon saglanacaktir, bu durumda stack adresi daha buyuktur.

peki bu bizim icin neden onemli?

uVar4 burada 0x20 degerine esitleniyor ve disassembly ciktisina baktigimizda uVar4 aslinda RAX register'i. asagidaki if blogu, uVar4 < 0x20 kondisyonu saglanmadigi icin atlaniyor. sonrasinda shellcode'umuz calistiriliyor, yani o virtual memory adresine call ile ziplaniyor. en son olarak AL register'inin son 8 bitinin 0 olup olmadigini kontrol ediyor. eger 0 degilse basardigimizi bildiriyor.

zaten AL register'inin programin kendisi tarafindan dolayli olarak degistirildigini firsat bilip sadece ret (0xC3 yani sadece Ã karakterini input olarak girmemiz gerek klavye ile) instruction'iyla fonksiyonun kaldigi yere geri donup crackme'yi kirabiliyoruz. konuda 4 bayt kullanilmisti, biz 1 bayt kullanarak basari mesajini almayi basardik

Mysorfilox · 9 Ocak 2026

drag4n' Alıntı:
Challenge:

koboldschwaengel's Password or Payload?

I guess there ist only one way to find the answer. Have fun!

crackmes.one

İyi günler, iyi akşamlar. Dün karşıma çıkan güzel bir shellcode mantığı içeren "Password or Payload" challenge'ını inceleyeceğiz. Program bizden bir şifre istiyor ama author'un bahsettiği üzere "Input injector yok, sadece klavye serbest" demiş. Yani elimizdeki kısıtlı karakter setiyle (printable ASCII) programın akışını yönlendirmemiz lazım. Klasik bir "şifreyi bul" sorusu değil, daha çok "geçerli bir kod yaz ve çalıştır" sorusu.

1. Recon
Binary'yi IDA Pro ile açarak analize başlıyoruz. İlk olarak programın yapısını anlamak için Strings penceresini kontrol ediyoruz. Burada, programın çalışma zamanında kullanıcıya gösterdiği "Enter the Password:", "pass is correct!" ve "passwort is incorrect" gibi geri bildirim mesajları açıkça görülüyor.

Bu mesajlar, ilk bakışta programın standart bir "şifre doğrulama" işlemi yapacağı izlenimini veriyor. Ancak bu varsayımı doğrulamadan önce programın hangi API'leri kullandığına bakmamız şart.

Import Table'ı incelediğimizde dikkat çekici bir detayla karşılaşıyoruz:

Program, VirtualAlloc fonksiyonunu import ediyor. Basit bir metin karşılaştırma programının, Windows'tan manuel olarak bellek tahsis etmesi (memory allocation) olağan bir durum değil. Bu API genellikle dinamik kod çalıştırma veya unpacking işlemlerinde kullanılır. Bu aşamada, programın basit bir crackme'den fazlası olabileceğine dair ilk ipucumuzu alıyoruz.

2. Derin Analiz: Code Execution Mantığı
Şüphelerimizi doğrulamak için main fonksiyonunu inceliyoruz. Kod akışının, standart bir karşılaştırma (if password == input) algoritmasından çok farklı olduğunu görüyoruz.

A. Input Alımı ve Bellek Tahsisi

Önce fgets ile bizden input alınıyor.

Hemen ardından VirtualAlloc çağrılıyor. Burada en kritik detay r9d register'ına atanan değerdir.

"mov r9d, 40h" Bu 0x40 değeri, Windows API'sinde PAGE_EXECUTE_READWRITE iznine denk gelir. Yani bu bellek alanı, içine veri yazıp kod çalıştırabileceğimiz özel bir alandır.

B. Shellcode Çalıştırma ve Karar Mekanizması

Program, bizim input'umuzu RWX belleğe kopyaladıktan sonra onu kod olarak çalıştırıyor. Aşağıdaki grafikte bu akışı net görebilirsiniz:

Grafiği adım adım inceleyelim:

call rdi rdi register'ında tutulan adrese (bizim input'umuzun kopyalandığı RWX bellek) dallan ve oradaki kodu çalıştır.
test al, al Çalıştırılan kodun dönüş değerini (AL register) kontrol et. AL, RAX'ın alt 8 bit'idir.
lea rcx, "pass is correct!" Önce success string'ini RCX'e yükle (puts için hazırlık).
jnz short loc_140001125 Eğer AL ≠ 0 ise puts'a (loc_140001125) atla ve "pass is correct!" yazdır.
lea rcx, "passwort is incorrect" Eğer AL = 0 ise bu satıra düşer ve fail string'i yüklenir.

Özetle program bizden şunu istiyor. "Bana öyle karakterler ver ki, ben bunları makine kodu (opcode) olarak çalıştırdığımda, bana 0 olmayan bir sonuç (return value) ile geri dön."

3. Keyboard-Only Shellcode
Normal şartlarda, bir fonksiyondan 1 (true) döndürmek için Assembly'de şu basit iki satırı yazarız:

mov al, 1 AL = 1
ret Return

Bu kodun makine dili karşılığı: B0 01 C3.

Fakat daha önce bahsettiğim üzere. Sadece klavye kullanabiliriz. B0 (mov al) byte'ı, standart ASCII tablosunda basılabilir bir karaktere denk gelmiyor. Hex editör kullanamadığımız için, sadece klavyedeki harflerle aynı işi yapan alternatif bir opcode zinciri kurmamız gerekiyor.

Çözüm Matrisi
Hedefimiz yukarıda bahsettiğimiz AL register'ını 0 dışı bir değer yapmak ve ret ile çıkmak.

ADIM 1: push 0x31

Opcode 6A 31
Klavye j1
Ne yapıyor? 0x6A (push imm8) komutu j harfine denk gelir. Arkasındaki 0x31 ise 1 karakteri. Stack'e 0x31 (decimal 49) değerini atıyoruz.

ADIM 2: pop rax

Opcode 58
Klavye X
Ne yapıyor? Stack'teki 0x31 değerini RAX register'ına çekiyoruz. RAX'ın alt 8 bit'i AL olduğu için artık AL = 0x31 (sıfır değil!).

ADIM 3: ret

Opcode C3
Klavye À (Alt+0192 veya kopyala-yapıştır)
Ne yapıyor? İşin zor kısmı burası.... Program UTF-8 modunda çalışıyor (SetConsoleCP(65001)). À karakteri UTF-8'de C3 80 olarak kodlanır. İlk byte C3 = ret komutu, fonksiyondan çıkıyoruz. İkinci byte (80) ise ret'ten sonra geldiği için CPU buraya hiç ulaşmıyor yani önemsiz.

4. Payload ve Sonuç
Final payload'ımız şu 4 karakterden oluşuyor: j1XÀ

Gördüğünüz üzere payloadımız çalıştı. Eğer buraya kadar okuduysanız ve aklınızda herhangi bir soru varsa sorabilirsiniz.

Not: Bunu çözerken bir kaç kaynaktan yardım almıştım ayrıca. Göz atmak isteyen varsa onları da ekliyorum.

Shellcode ve Process Injection

Windows Process Injection Fundamentals — VirtualAlloc, WriteProcessMemory ve shellcode çalıştırma temelleri.

Loading and Executing Shellcode From PE Resources (ired.team) — Visual Studio ile shellcode yükleme ve çalıştırma.

What is Process Injection? Techniques & Preventions (SentinelOne) — Process injection tekniklerine genel bakış.

x86-64 Opcode Referansları

X86 Opcode and Instruction Reference (coder64) — 64-bit opcode tablosu, her instruction'ın byte karşılıkları.

Intel x86 Opcode Table (shell-storm) — Kapsamlı Intel opcode referansı.

Stanford CS107 x86-64 Reference Sheet (PDF) — Hızlı başvuru için özet tablo.

Alphanumeric / Printable Shellcode

Alphanumeric Shellcode (Offensive Security) — Metasploit ile alphanumeric shellcode üretimi.

ASCII Shellcode (NetSec) — Printable karakter kısıtlamalarıyla shellcode yazma.

Linux Alphanumeric Shellcode — Sadece alfanumerik karakterlerle execve() shellcode.

UTF-8 ve Unicode Shellcode

UTF-8 Shellcode (Phrack #62) — UTF-8 encoding ile shellcode bypass teknikleri. (Klasik makale)

Writing Unicode Payloads (Venetian Shellcode) — Unicode kullanan uygulamalarda exploit geliştirme.

eline sağlık

mehve · 24 Ocak 2026

elinize sağlık teşekkürler

[Writeup] Password or Payload? – Keyboard-Only Shellcode Analizi

drag4n

Yeni üye

koboldschwaengel's Password or Payload?

1. Recon

2. Derin Analiz: Code Execution Mantığı

3. Keyboard-Only Shellcode

Çözüm Matrisi

4. Payload ve Sonuç

an0un

Kıdemli Üye

drag4n

Yeni üye

Napcaz

Katılımcı Üye

Abusing Exceptions for Code Execution, Part 2

Boots for Walking Backwards: Teaching pefile How to Understand SEH-Related Data in 64-bit PE Files

drag4n

Yeni üye

Abusing Exceptions for Code Execution, Part 2

Boots for Walking Backwards: Teaching pefile How to Understand SEH-Related Data in 64-bit PE Files

aga67

Yeni üye

Abusing Exceptions for Code Execution, Part 2

Boots for Walking Backwards: Teaching pefile How to Understand SEH-Related Data in 64-bit PE Files

Mysorfilox

Katılımcı Üye

koboldschwaengel's Password or Payload?

1. Recon

2. Derin Analiz: Code Execution Mantığı

3. Keyboard-Only Shellcode

Çözüm Matrisi

4. Payload ve Sonuç

mehve

Yeni üye

Sosyal medya sayfalarımız

[Writeup] Password or Payload? – Keyboard-Only Shellcode Analizi

Yeni üye

1. Recon​

2. Derin Analiz: Code Execution Mantığı​

3. Keyboard-Only Shellcode​

Çözüm Matrisi​

4. Payload ve Sonuç​

Kıdemli Üye

Yeni üye

Katılımcı Üye

Yeni üye

Yeni üye

Katılımcı Üye

1. Recon​

2. Derin Analiz: Code Execution Mantığı​

3. Keyboard-Only Shellcode​

Çözüm Matrisi​

4. Payload ve Sonuç​

Yeni üye

1. Recon

2. Derin Analiz: Code Execution Mantığı

3. Keyboard-Only Shellcode

Çözüm Matrisi

4. Payload ve Sonuç

1. Recon

2. Derin Analiz: Code Execution Mantığı

3. Keyboard-Only Shellcode

Çözüm Matrisi

4. Payload ve Sonuç