
Turkish: 
Bu videoda 0 seviyesinden yığın seviyesini kapsayacağız
exploit-exercises.com/protostar.
Öbek sömürüsünün tanıtıcısı
meydan okumak ve çok kolaydır.
Bunu yine Ubuntu 16.04 LTS'de derledik.
sürüm, yani temelde modern bir sistem için
bakalım hala nasıl sömürülebilir.
Ve spoiler uyarısı, bunun için hiçbir şey değişmedi
meydan okur, bu son derece basittir.
Ama bu video için özel bir fikrim var.
senin için biraz kolay olsa bile
başka neler öğrendiğimizi kontrol etmek istiyorum
son.
Bu serinin önceki videolarında genellikle
sömürüyü yaratın ve sonra bir yol düşünün
size nasıl açıklanacağı ve gösterileceği.
Ama bu o kadar basit ki düşündüm ki
kendimi çözerken kaydettiğimde havalı olun
bu, bir tür kör ya da sürat koşusu gibi.
Ama süper hızlı olmaya çalışmadım ama
oldukça yalındır ve hepsini dahil ediyorum

English: 
In this video we will cover heap level 0 from
exploit-exercises.com/protostar.
It’s the heap exploitation introductory
challenge and is very easy.
We again compile this on a Ubuntu 16.04 LTS
version, so basically a modern system, to
see if or how it’s still exploitable.
And spoiler alert, nothing changed for this
challenge, it’s super straight forward.
But I have a special idea for this video and
even if it’s a bit easy for you, you might
want to checkout what else we learn at the
end.
In the previous videos of this series I usually
create the exploit and then think of a way
how to explain and show it to you.
But this is so simple, that I thought it would
be cool if I would instead record myself solving
it, kind of like a blind solve or a speedrun.
But I didn’t try to be super fast but it
was quite straight forward and I include all

English: 
the mistakes and pauses I made.
And now we will step through the video and
I explain to you what I have been thinking
in different moments and point out some other
things.
In the top right corner you can also see a
timer that will keep track of how long it
took me in real time.
But before we start doing the exploit let’s
have a look at the code again.
There are two functions winner() and nowinner().
And obviously we have to somehow call winner().
We can also see there are two structs that
get space allocated for them on the heap.
And this fp construct here looks complex,
but you can ignore that weirdness because
when you look in the code it’s clear what
it does.
We set fp to nowinner.
Notice how nowinner has no parantheses, this
means it’s not being called.
This is literally the function pointer and
adding paraentheses would cause a call.
And then later we have those paraentheses
for fp.

Turkish: 
yaptığım hataları ve duraklamaları.
Ve şimdi videoya geçeceğiz ve
Sana ne düşündüğümü açıkladım
farklı anlarda ve bazı diğer işaret
eşyalar.
Sağ üst köşede ayrıca bir
ne kadar süreceğini takip edecek zamanlayıcı
beni gerçek zamanlı olarak aldı.
Ama istismar yapmadan önce hadi
tekrar koda bir göz atın.
Winner () ve nowinner () olmak üzere iki fonksiyon vardır.
Ve belli ki bir şekilde kazananı çağırmamız gerekiyor ().
Ayrıca iki yapı olduğunu görebiliriz.
öbek üzerinde onlar için ayrılan yer elde edin.
Ve bu fp yapı burada karmaşık görünüyor
ama bu tuhaflığı görmezden gelebilirsin çünkü
koda bakıldığında ne olduğu açık
öyle.
Şimdilik fp'yi ayarladık.
Ne kadar aceminin parantezleri olmadığını fark et.
aranmadığı anlamına gelir.
Bu tam anlamıyla işlev gösterici ve
parantez eklemek bir aramaya neden olur.
Sonra da parantezlerimiz var.
fp için.

English: 
And fp has been set to point to nowinner,
so nowinner is executed().
And our goal is it to somehow use the strcpy,
which will overflow the name buffer which
is only 64byte large and overwrite the function
pointer.
So sounds easy.
I start by opening up the binary in gdb.
And do a first test execution, but I run into
a segfault which startled me for a few seconds,
but then I realized I forgot the argument
parameter again.
The strcpy uses the first argument to copy
into name.
Ok now we had a clean execution.
Now I want to set a good breakpoint so I disassemble
main.
I’m quickly scanning the assembler code
here, mainly looking at the different function
calls to figure out what corresponds to what
in the C code.
And at first I was thinking about setting
a breakpoint before or after the strcpy, to
catch the before and after of the overflow,
but in the last moment then figured that I

Turkish: 
Ve fp şu an için olanları göstermeye ayarlandı.
bu yüzden nowinner yürütülür ().
Ve amacımız strcpy'yi bir şekilde kullanmak.
hangi isim tamponunu taşacak
64 bit büyüklüğünde ve fonksiyonun üzerine yazılır
Işaretçi.
Kulağa kolay geliyor.
Ben gdb'de ikiliyi açarak başlıyorum.
Ve bir ilk test uygulaması yap, ama ben rastladım
beni birkaç saniye şaşırtan bir segfault,
ama sonra farkettim ki tartışmayı unuttum
tekrar parametre.
Strcpy kopyalamak için ilk argümanı kullanır.
adına.
Tamam, şimdi temiz bir infaz yaptık.
Şimdi iyi bir kesme noktası belirlemek istiyorum.
ana.
Assembler kodunu hızlıca tarıyorum
burada, esas olarak farklı işleve bakıyor
neyin neye karşılık geldiğini anlamaya
C kodunda
Ve ilk başta ayar yapmayı düşünüyordum
strcpy’den önce veya sonra
taşma işleminden önce ve sonra yakalamak,
ama son anda o zaman anladım ki

English: 
probably don’t need to look at it this closely,
and I can simply go to the magic position
right away.
The call rdx.
This is calling the function pointer that
contains nowinner().
Ok, so I execute it again and we hit the breakpoint.
Now this challenge is about a heap overflow,
so I first check the virtual memory map of
the process with vmmap.
Here you can see in which memory regions we
have the binary itself with the code and data
segments, we can also see where the stack
is and where shared libraries like libc are
loaded too, and we also have the heap here.
So obviously I want to check out how the heap
looks like.
Examine 32 64bit hex values from the start
of the heap.
I immediately look for the name we entered
as an argument, which was “AAAA”, so here
they are.
And I also immediately look for the function
pointer.
This looks like an address.
Quick sanity check with the disassemble command.
Here is a puts call using this address as
a paremter, and so that is our nowinner string.

Turkish: 
muhtemelen buna yakından bakmak gerekmez
ve ben sadece sihir konumuna gidebilirim
derhal.
Çağrı rdx.
Bu işlev işaretçisi çağırıyor
nowinner () öğesini içerir.
Tamam, tekrar çalıştırıyorum ve kesme noktasına geldik.
Şimdi bu zorluk bir yığın taşması ile ilgili.
bu yüzden önce sanal bellek haritasını kontrol ediyorum.
vmmap ile işlem.
Burada hangi hafıza bölgelerinde bulunduğumuzu görebilirsiniz.
İkili kod ve verilerle birlikte
kesimleri, yığının nerede olduğunu da görebiliriz.
libc gibi paylaşılan kütüphanelerin olduğu yer
çok yüklü ve ayrıca burada yığın var.
Açıkçası, nasıl bir yığın olduğunu kontrol etmek istiyorum.
benziyor.
32 64bit hex değerlerini baştan inceleyin
Yığın
Hemen girdiğimiz adı arıyorum.
“AAAA” olan bir argüman olarak, işte burada
onlar.
Ve ayrıca hemen işlevi arıyorum
Işaretçi.
Bu bir adres gibi görünüyor.
Sökme komutuyla hızlı sağlık kontrolü.
İşte bu adresi kullanarak bir çağrı koyar.
bir paremter, ve işte bu bizim acemi dizemiz.

Turkish: 
Yani evet, bu şu anda iç kısımda.
Şimdi kazananın üzerine yazmak istiyoruz.
bu yüzden bu adrese ihtiyacımız var.
İşte burada.
Sonra ne kadar elimizde olduğunu bulmam gerek
taşması, bunu yapmak için sadece bakıyorum
sola doğru adreslenir.
Adın başlangıcı adresi 0x10 ile biter,
ve işlev işaretçisi ath 0x60.
Demek ki 0x50 dengelememiz var.
Şimdi kendimi güvende hissediyorum ve aslında
gdb'den ayrılma ve çalışmayı umma
hemen istifade etmek.
Bu yüzden kısa bir python satır içi yazarak başla
exploit dizesini basmak için script.
Temelde birkaç karaktere ihtiyacımız var.
işlev işaretçisine ulaşmak için
bu yüzden birkaç As yazdırırım.
Hızlı kontrol tekrar kaç tane, 0x60-0x10 oldu
bu yüzden 0x50'ye ihtiyacımız var.
Bundan sonra kazanan adrese ihtiyacımız var.
Öyleyse 0x40, OOPS!
Neredeyse bir hata yaptım - bu stil oluyor
bana bir ara, belli ki başlamak zorundayız

English: 
So yep, that’s nowinner.
So now we want to overwrite that with winner,
so we need that address.
Here it is.
Next I need to figure out how much we have
to overflow, to do that I simply look at the
addresses to the left.
Address of the start of the name ends in 0x10,
and the function pointer is ath 0x60.
So we have an offset of 0x50.
So now I’m feeling confident and actually
drop out of gdb and hope to have a working
exploit right away.
So I start by writing a short python inline
script to print the exploit string.
Essentially we need a couple of characters
as padding to reach the function pointer and
so I print a few As.
Quick check again how many that was, 0x60-0x10
so we need 0x50.
After that we need the address of winner.
So 0x40, OOPS!
Almost made a mistake - this stil happens
to me sometime, we obviously have to start

English: 
with 0xf6, 0x05 and then 0x40.
Because of the endianess.
Now for a sanity and debugging step I pipe
that output into hexdump to see if it is what
I expect.
But then I notice a 0x0a at the end, and that’s
a newline.
Python print will add a newline at the end
which we don’t want.
So now I change the script to use the sys
module instead in order to directly write
a string to stdout, so we don’t have a newline.
And I verify that again with hexdump.
And then I’m basically done and try it on
the target binary.
So the input is passed as argument, so I use
backticks to execute the inner python command,
and the output is then basically replaced
by it and placed here as the arguments.
Level passed!
Awesome!
I executed the winner function().
You see this was super simple.

Turkish: 
0xf6, 0x05 ve sonra 0x40 ile.
Endianess yüzünden.
Şimdi bir akıl sağlığı ve hata ayıklama adım için ben boru
Bu olup olmadığını görmek için hexdump içine çıktı
Bekliyorum, umuyorum.
Ama sonunda bir 0x0a farkettim ve bu
bir yeni hat.
Python print sonunda yeni bir satır ekleyecek
ki biz istemiyoruz.
Şimdi sys kullanmak için komut dosyasını değiştiriyorum
doğrudan yazmak için modül yerine
stdout'a bir string, yani yeni bir hattımız yok.
Ve bunu tekrar hexdump ile doğrularım.
Ve sonra temelde bittim ve denedim
Hedef ikili.
Böylece girdi argüman olarak iletilir, bu yüzden kullanıyorum
iç python komutunu çalıştırmak için backticks,
ve çıktı daha sonra temel olarak değiştirilir
onun tarafından ve argümanlar olarak buraya yerleştirilir.
Seviye geçti!
Korku veren!
Kazanan işlevi () çalıştırdım.
Görüyorsun, bu süper basitti.

English: 
So when I was writing this script with the
commentary of my recording, I noticed a small
detail that I didn’t think about.
And I actually never thought about before.
So here is the heap output again.
Do you see this data down here?
That is clearly ascii.
And that’s weird, in our program we did
not allocate any string like this on the heap.
So how did this happen?
When you look at this ascii text, then you
will realize it’s in fact the printf output.
But why is that on the heap?
Let’s investigate.
First I thought we could checkout valgrind.
Valgrind is an instrumentation framework for
building dynamic analysis tools.
There are Valgrind tools that can automatically
detect many memory management and threading
bugs, and profile your programs in detail.
I really should use valgrind more often, I
use it wayy to little.
But here is for example the valgrind output
with tracing mallocs enabled.
And then we run our heap0 level.
And we can indeed see here our two mallocs
of the structs we do, but also a malloc we

Turkish: 
Yani ben bu senaryoyu yazarken
kaydımın yorumunda küçük bir fark ettim
Ben düşünmedim detay.
Ve aslında daha önce hiç düşünmedim.
Yani burada yine yığın çıktısı var.
Bu verileri aşağıda görüyor musunuz?
Bu açıkça ascii.
Ve bu garip, programımızda yaptığımız
Öbek üzerinde böyle bir dize tahsis etmeyin.
Peki bu nasıl oldu?
Bu ascii metne baktığınızda
aslında printf çıktısını anlayacaktır.
Ama neden bu öbek üzerinde?
Araştıralım.
İlk önce valgrind'i kontrol edebileceğimizi düşündüm.
Valgrind bir araç çerçevedir
dinamik analiz araçları oluşturma.
Otomatik olarak yapabilen Valgrind araçları var
birçok bellek yönetimi ve iş parçacığını algıla
hataları ve programlarınızı ayrıntılı bir şekilde görüntüleyin.
Valgrind'i daha sık kullanmalıyım,
çok az kullan.
Ancak burada örneğin valgrind çıktısı
izleme mallocs etkinken.
Ve sonra yığın0 seviyemizi yükseltiriz.
Ve gerçekten burada iki mallocumuzu görebiliriz.
Yaptığımız yapıların yanı sıra, aynı zamanda

Turkish: 
1024 yapmadım.
Aynı zamanda serbest kalan tek hafıza.
tekrar.
Malloc'larımız özgür değil.
Peki bu neden oluyor?
Başka ilginç çıktı strace.
Strace sistemlerini izler.
Ve biz burada mallocs görmüyoruz, çünkü
malloc sadece bazı algoritma ve hafıza yönetimi
libc içinde uygulanmış brk sistem çağrısını görebiliriz,
işletim sisteminden bellek alan
ilk etapta.
Demek ki anı alacağımız yer burası.
Yığın için libc tarafından kullanılmalıdır.
Eğer malloc bir libc işlevi ise, biz de
bağlantılı dinamiği izleyen çıkış ltrace
Kütüphane işlevi çağırır.
Ama garip bir şekilde, sadece iki mallocs görüyoruz.
iki yapı.
Gizemli üçüncü malloc hakkında hiçbir şey yok.
Hemen anlaşılmayabilir, ama bu
aslında zaten gerçekten çok iyi bir ipucu
gizemli malloc olmadı
dinamik olarak bağlanmış bir kütüphane çağrısı.

English: 
didn’t do of 1024.
That’s also the only memory that is freed
again.
The mallocs we do have no free.
So why is that happening?
Another interesting output is strace.
Strace traces syscalls.
And while we don’t see mallocs here, because
malloc is just some algorithm and memory managment
implemented in libc, we can see the brk syscall,
which gets the memory from the operating system
in the first place.
So this is where we get memory that will then
be used by libc for the heap.
So if malloc is a libc function, we can also
checkout ltrace, which traces linked dynamic
library function calls.
But oddly enough we only see two mallocs for
the two structs.
Nothing about the mysterious third malloc.
It might not be immediately obvious, but that
is actually already a really good hint that
the mysterious malloc did not happen from
a dynamically linked library call.

Turkish: 
Bu, bu mallocun infaz edilmiş olması gerektiği anlamına gelir.
örneğin libc'nin kendisi tarafından.
Ve valgrind biraz daha akıllı ve ayrıca izler
bu iç mallocs.
Üçüncü test için basit bir program oluşturdum
Bu koyar çağırır, bu yüzden bir dize yazdırır.
Çünkü yığının printf içerdiğini biliyoruz.
çıktı bir şey yapmalı
söyledi.
Ve sonra o programda hata ayıklayabilir ve ayarlayabiliriz.
brk üzerinde bir kesme noktası.
Unutma brk, çağrılan sistemdir.
bir program ek sanal istediğinde
bellek ve öylesine ne zaman yığın denir
ayarlandı.
Ve yığın her zaman kurulum değildir, yalnızca
gerekli.
Eğer printf varsayarsak ya da malloc'u çağırırsak,
önce yığını ayarlamak zorunda kalacaktı.
Şimdi bu yüzden bu küçük yarattı
Test programı, çünkü orijinal yığın0
printf’ten önce belli ki normal mallocs,
Bu biraz can sıkıcı hale getirir, bu yüzden
temiz bir örnek.
İkinci bir notta, bir kesme noktası ayarladığınızda
brk gibi bir sembol ismi ile
bunun için bir sembol adı olun.

English: 
Which means, this malloc must have been executed
for example by libc itself.
And valgrind is a bit smarter and also traces
these internal mallocs.
For the third test I create a simple program
that calls puts, so it prints a string.
Because we know the heap did contain the printf
output so it must have to do something with
that.
And then we can debug that program and set
a breakpoint on brk.
Remember brk is the syscall that is called
when a program requests additional virtual
memory, and so this is called when the heap
is set up.
And the heap is not always setup, only if
it is required.
So if we assume printf or puts calls malloc,
it would have to setup the heap first.
Now that’s also why I created this small
test program, because the original heap0 has
obviously regular mallocs before the printf,
which makes it a bit annoying, so this is
a clean example.
On a second note, when you set a breakpoint
with a symbol name like brk, there has to
be a symbol name for it.

Turkish: 
Ve bir sistemin bir sembol ismi yok.
Bir çağrı bir montajcı kesinti talimatıdır
hangisini belirteceğini belirtmek için
İstediğin çağrı.
Ama bir brk sembolü var, ama değil
başlangıçta bulundu.
Öncelikle programı çalıştırmak zorundasınız.
Dinamik kütüphane libc yüklemek için
bir brk sembolü içerir.
Ve infact, normal bir fonksiyon olarak
brk sistem etrafındaki sarıcı.
Yani libc içindeki herhangi bir şey doğrudan olmaz
Syscall kesinti yaparsa,
dahili brk işlevi.
Dolayısıyla, bu yüzden kolayca bir kırılma noktası ayarlayabiliriz.
bunun gibi.
Uzun lafın kısası şimdi devam edip vurabiliriz
bu kesme noktası ve ardından işlevi inceleyin
hangi fonksiyonların bize sahip olduğunu söyleyen backtrace
Bu brk aramasına yol açan çağrıldı.
Bunu biraz temizliyorum.
İşte başlıyoruz.
Ve gördüğünüz gibi IO_puts ile başlar.
Bunun için libc koduna da bakabilirsiniz.
şey, az önce bir libc aynası buldum

English: 
And a syscall doesn’t have a symbol name.
A syscall is an asembler interrup instruction
with a number as paramter to indicate which
syscall you want.
But there is a brk symbol, but it’s not
initially found.
You first have to execute the program in order
to load the dynamic library libc, which does
contain a brk symbol.
And infact that is a regular function as a
wrapper around the brk syscall.
So anything inside of libc would not directly
do the syscall interrupt, it would call the
internal brk function.
So that;s why we can easily set a breakpoint
like this.
Long story short we can now continue and hit
that breakpoint and then examine the function
backtrace which tells us which functions have
been called that lead to this brk call.
I clean that up a bit.
So here we go.
And as you can see it starts with IO_puts.
You can also look at the libc code for that
stuff, I just pulled up some mirror of libc

English: 
on github, and you can read the code there.
The reason why the function is not called
puts, but IO_puts, eventhough we only use
puts when we call it, has to do with a lot
of C macros in libc.
I find it really difficult to read that code.
For example we know that the next function
has the symbol name _IO_new_file_xsputn, but
that doesn’t show up in the C code.
But there is this similarely called IO_sputn,
which when you look that up leads to a macro
that says that it’s actually IO_Xsputn.
Which itself is another macro that is JUMP2
with __xsputn as the first argument , and
JUMP2 is obviously another macro.
And it just keeps going like that.
Feel free to do that on your own.
But if we trust our trace we can see that
at some point it calls doallocbuffer.
And there is also a comment saying: “Allocate
a buffer if needed”.

Turkish: 
github’da, kodu orada okuyabilirsiniz.
İşlevin çağrılmamasının nedeni
koyar, ancak IO_puts, yalnızca kullandığımız halde
biz diyoruz koyar, çok yapmalı
C makrolarının libc içindeki.
Bu kodu okumak gerçekten zor.
Mesela bir sonraki fonksiyonun
_IO_new_file_xsputn sembolüne sahip, ancak
Bu C kodunda görünmüyor.
Ancak buna benzer şekilde IO_sputn denir,
o baktığınızda bir makroya yol açar
Bu aslında IO_Xsputn olduğunu söylüyor.
JUMP2 olan başka bir makro hangisidir?
ilk argüman olarak __xsputn ile ve
JUMP2 açıkçası başka bir makro.
Ve sadece böyle devam ediyor.
Bunu kendi başınıza yapmaktan çekinmeyin.
Ama izimize güvenirsek, bunu görebiliriz.
Bir noktada doallocbuffer çağırır.
Ayrıca şöyle bir yorum var: “Tahsis Et
gerekirse bir tampon ”.

Turkish: 
Yani bu 1024 bayt malloc ile yapmak zorunda
standart çıktı tamponu.
Bir printf anında bir sonuç vermez.
Syscall yazma, ancak libc çok uygular
daha yüksek seviyelere ulaşmak için bunun gibi şeyler
yerine çıktıyı arabelleğe alarak performans
dosya beklemek veya biraz daha büyük yazmak
çok küçük parçalar yerine topakları.
Evet.
Bunun çözülmüş bir gizem olduğunu düşünürdüm.
İçsel çalışmalara sadece küçük bir gezi
Programların
Umarım bundan hoşlanmışsındır.
Haftaya görüşürüz.

English: 
So this 1024 byte malloc has to do with the
standard output buffer.
A printf doesn’t immediatly result in a
syscall write, but libc implements a lot of
stuff like this in order to achieve higher
performances by buffering output instead of
waiting for files, or writing a few bigger
chunks instead of a lot of small pieces.
Yeah.
I would consider this a solved mystery.
Just a little excursion into the inner workings
of programs.
I hope you liked that.
See you next week.
