kralhakan2009 1
kralhakan2009
noisiv 1
noisiv
Manwe Work 1
Manwe Work
Vahsi Uzman 1
Vahsi Uzman
Cannn6161 1
Cannn6161
B 1
berione65
sen272 1
sen272
Mt2Hizmet 1
Mt2Hizmet
C 1
chengdu
Hikaye Ekle
Reklam vermek için turkmmo@gmail.com

Buffer Exploit

  • Konuyu başlatan Konuyu başlatan Silverhand
  • Başlangıç tarihi Başlangıç tarihi
  • Cevaplar Cevaplar 90
  • Görüntüleme Görüntüleme 8K
  • Etiketler Etiketler
    bufferexploit

ROHAN2 WORLD 1-120 TR TİPİ OFFICIAL YOHARA, BALATHOR VE AMON! 80. GÜNÜNDE! +10.000 ONLİNE! HİLE VE BOT %100 ENGELLİ HEMEN TIKLA!

Diğer konudan daha yararlı, daha çözüm odaklı ama hala eksikler var, game dosyanız x86 çalışıyorsa evet ram doldurma sorununuza kısa vadede yarar sağlayabilir.
First-start'da limitlendirme kullanmak sağlıklı değil bunu bir ayara veya bir boot event'e bağlayıp bir süre sonra işleve alın ki oyuncunuz ilk girişte sorun yaşamasın(otologin kullanıyorsanız da aynı durum)
Hala ne kadar srcden de engel koymanız gerekli olsa da kullanılan host firmalarının da çözüm sağlaması gerekli düşüncesiyle Emre abi ile gece gündüz saatlerce tartışıp dediğim mantığın kafasına yattığından beri o mutlu - ben mutlu

eline sağlık @Silverhand

Deryama deniz olan denizim gelmiş hoş gelmiş.

 
Diğer konudan daha yararlı, daha çözüm odaklı ama hala eksikler var, game dosyanız x86 çalışıyorsa evet ram doldurma sorununuza kısa vadede yarar sağlayabilir.
First-start'da limitlendirme kullanmak sağlıklı değil bunu bir ayara veya bir boot event'e bağlayıp bir süre sonra işleve alın ki oyuncunuz ilk girişte sorun yaşamasın(otologin kullanıyorsanız da aynı durum)
Hala ne kadar srcden de engel koymanız gerekli olsa da kullanılan host firmalarının da çözüm sağlaması gerekli düşüncesiyle Emre abi ile gece gündüz saatlerce tartışıp dediğim mantığın kafasına yattığından beri o mutlu - ben mutlu

eline sağlık @Silverhand

metin2 de paketler genelde çok küçük handshake auth login move attack sohbet item kullanımı vs hepsi kb seviyesinde, tek pakette 8mb'a yaklaşan normal bir oyun paketi yok,( tek istisna 8mbı aşan çok özel custom sistemler belki) ilk giriş ve otologin de aynı küçük paketlerle çalışıyor. yani normal oyuncu bu limitlere takılmaz

boot event veya delay bence gereksiz çünkü limitler sürekli aktif , sadece büyük veya şüpheli veri geldiğinde devreye girer.

x86 x64 fark etmez limit kodda if (size > X) return veya abort gibi basit bir kontrol bu mantık her mimaride aynı şekilde çalışır diye biliyorum.

Host tarafı da önemli ama buffer overflow tek başına host ile çözülemez, kod fixi zorunlu çünkü TCP içeriği söz konusu buffer allocation uygulamada olur bunuda sadece kaynak koddaki limit engelleyebilir.

Yukarıdakiler kişisel fikrim yanlış anlaşılma olmasın lütfen.


bu paylaşılan fixde benim paylaştığımdan çok çok iyi yerleri var örneğin ; buffer_new abort yerine return null , buffer realloc : return , buffer write limit aşımında return ve yine çökme olmuyor , 8mb limit (ben 64 yapmıştım aceleyle) daha dar sıkı ama benzer mantık ama güvenlik açısından daha kararlı.

riskli tarafları ise bence ;

- Buffer sıfırlanıyor, ama return -1 ile bağlantı kesme her durumda garantili değil yani sadece buffer reset ediliyor ve bağlantı her seferinde kapanmayabilir.
- m_lpInputBuffer ikinci kez buffer_new ile çift buffer oluşturma ve olası memory leak gibi sanki. bunlar haricinde çok inceleyemedim.


[CODE title="selana sinwar"]#0 thr_kill () at thr_kill.S:4
warning: 4 thr_kill.S: No such file or directory
[Current thread is 1 (LWP 103298)]
(gdb) bt
#0 thr_kill () at thr_kill.S:4
#1 0x28c8ba8b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:50
#2 0x28d356fb in abort () at /usr/src/lib/libc/stdlib/abort.c:64
#3 0x083f7168 in buffer_new (size=<optimized out>, size@entry=218381008)
at buffer.c:101
#4 0x083f7262 in buffer_new (size=218381008) at buffer.c:77
#5 buffer_realloc (buffer=@0xffff7a54: 0x2b059d60,
length=length@entry=218381008) at buffer.c:262
#6 0x083f7390 in buffer_realloc (length=218381008,
buffer=@0xffff7a54: 0x2b059d60) at buffer.c:259
#7 buffer_write (buffer=@0xffff7a54: 0x2b059d60, src=0x788a0b00,
length=218362576) at buffer.c:153
#8 0x08084441 in TEMP_BUFFER::write (this=0xffff7a54, data=0x788a0b00,
size=218362576) at buffer_manager.cpp:28
#9 0x0811b4b9 in DESC::ProcessInput (this=0x41279e00) at desc.cpp:304
#10 0x082848a5 in io_loop (fdw=<optimized out>) at main.cpp:962
#11 0x08284ace in idle () at main.cpp:836
#12 idle () at main.cpp:800
#13 0x08071b1d in main (argc=1, argv=0xffffdc74) at main.cpp:488[/CODE]
 
Çok fazla kasmamak lazım :D
 
Paylaşım için teşekkürler.
 
metin2 de paketler genelde çok küçük handshake auth login move attack sohbet item kullanımı vs hepsi kb seviyesinde, tek pakette 8mb'a yaklaşan normal bir oyun paketi yok,( tek istisna 8mbı aşan çok özel custom sistemler belki) ilk giriş ve otologin de aynı küçük paketlerle çalışıyor. yani normal oyuncu bu limitlere takılmaz

boot event veya delay bence gereksiz çünkü limitler sürekli aktif , sadece büyük veya şüpheli veri geldiğinde devreye girer.

x86 x64 fark etmez limit kodda if (size > X) return veya abort gibi basit bir kontrol bu mantık her mimaride aynı şekilde çalışır diye biliyorum.

Host tarafı da önemli ama buffer overflow tek başına host ile çözülemez, kod fixi zorunlu çünkü TCP içeriği söz konusu buffer allocation uygulamada olur bunuda sadece kaynak koddaki limit engelleyebilir.

Yukarıdakiler kişisel fikrim yanlış anlaşılma olmasın lütfen.


bu paylaşılan fixde benim paylaştığımdan çok çok iyi yerleri var örneğin ; buffer_new abort yerine return null , buffer realloc : return , buffer write limit aşımında return ve yine çökme olmuyor , 8mb limit (ben 64 yapmıştım aceleyle) daha dar sıkı ama benzer mantık ama güvenlik açısından daha kararlı.

riskli tarafları ise bence ;

- Buffer sıfırlanıyor, ama return -1 ile bağlantı kesme her durumda garantili değil yani sadece buffer reset ediliyor ve bağlantı her seferinde kapanmayabilir.
- m_lpInputBuffer ikinci kez buffer_new ile çift buffer oluşturma ve olası memory leak gibi sanki. bunlar haricinde çok inceleyemedim.


[CODE title="selana sinwar"]#0 thr_kill () at thr_kill.S:4
warning: 4 thr_kill.S: No such file or directory
[Current thread is 1 (LWP 103298)]
(gdb) bt
#0 thr_kill () at thr_kill.S:4
#1 0x28c8ba8b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:50
#2 0x28d356fb in abort () at /usr/src/lib/libc/stdlib/abort.c:64
#3 0x083f7168 in buffer_new (size=<optimized out>, size@entry=218381008)
at buffer.c:101
#4 0x083f7262 in buffer_new (size=218381008) at buffer.c:77
#5 buffer_realloc (buffer=@0xffff7a54: 0x2b059d60,
length=length@entry=218381008) at buffer.c:262
#6 0x083f7390 in buffer_realloc (length=218381008,
buffer=@0xffff7a54: 0x2b059d60) at buffer.c:259
#7 buffer_write (buffer=@0xffff7a54: 0x2b059d60, src=0x788a0b00,
length=218362576) at buffer.c:153
#8 0x08084441 in TEMP_BUFFER::write (this=0xffff7a54, data=0x788a0b00,
size=218362576) at buffer_manager.cpp:28
#9 0x0811b4b9 in DESC::ProcessInput (this=0x41279e00) at desc.cpp:304
#10 0x082848a5 in io_loop (fdw=<optimized out>) at main.cpp:962
#11 0x08284ace in idle () at main.cpp:836
#12 idle () at main.cpp:800
#13 0x08071b1d in main (argc=1, argv=0xffffdc74) at main.cpp:488[/CODE]
haklısın evet, limitlendirmeleri buffer size için söylemedim ben zaten
 

Şu an konuyu görüntüleyenler (Toplam : 0, Üye: 0, Misafir: 0)

Geri
Üst