EMO Style ForumPro - Hos Geldiniz
Giriş yap

Şifremi unuttum

Istatistikler
Toplam 203 kayıtlı kullanıcımız var
Son kaydolan kullanıcımız: posta59

Kullanıcılarımız toplam 1186 mesaj attılar bunda 862 konu
Tarıyıcı
 Kapı
 Indeks
 Üye Listesi
 Profil
 SSS
 Arama
Arama
 
 

Sonuç :
 


Rechercher çıkıntı araştırma

RSS akısı


Yahoo! 
MSN 
AOL 
Netvibes 
Bloglines 


Anahtar-kelime

Kimler hatta?
Toplam 4 kullanıcı online :: 0 Kayıtlı, 0 Gizli ve 4 Misafir

Yok

[ Bütün listeye bak ]


Sitede bugüne kadar en çok 92 kişi Paz Ağus. 28, 2016 6:58 am tarihinde online oldu.
En son konular
» İnternetten Para Kazandıran Oyun ! Ödeme Alt Limiti Yok ! DEV KONU
Cuma Ağus. 29, 2014 8:33 am tarafından Hello EMO

» goldenchase.net maden yaparak para kazanma
Cuma Ağus. 29, 2014 8:18 am tarafından Hello EMO

» etichal hacker görsel egitim seti
Çarş. Ağus. 06, 2014 4:57 am tarafından Hello EMO

» KO TBL Source C#
Ptsi Ara. 09, 2013 6:36 am tarafından Hello EMO

» x86 Registers
C.tesi Ağus. 24, 2013 5:02 am tarafından Hello EMO

» [Tutorial] Pegando Address, Pointers de WYD
Çarş. Tem. 10, 2013 7:25 am tarafından Hello EMO

» [Tutorial] Pegando Address, Pointers de CS Metodo²
Çarş. Tem. 10, 2013 7:23 am tarafından Hello EMO

» [Tutorial] Aprendendo basico deASM OLLYDBG
Çarş. Tem. 10, 2013 7:22 am tarafından Hello EMO

» Basic C# DLL injector
Ptsi Tem. 08, 2013 7:48 am tarafından Hello EMO

Reklam

[1.298, 1.310/1.351/2.0] Friend report overflow

Önceki başlık Sonraki başlık Aşağa gitmek

[1.298, 1.310/1.351/2.0] Friend report overflow

Mesaj tarafından Hello EMO Bir Çarş. Şub. 23, 2011 8:28 am

[quote name='twostars' timestamp='1297199843' post='2717']
The CUser::FriendReport() overflow is probably one of the most stupid exploits MGame ever caused. Really, it's all just ignorance - typically, when one creates a buffer, they create it large enough to hold the most possible data that will ever be going into it. But no, MGame creates one so far underneath that (less than HALF - 256 bytes) it's just plain stupid.

Here's the function that's problematic. I've somewhat updated it to what it looks like in 1.298 (the problem, anyway).

Kod:
void CUser::FriendReport(char *pBuf)
{
   int index = 0; short usercount = 0, idlen = 0;
   int send_index = 0;
   char send_buff[256]; // ARRAY BEING OVERFLOWED
   memset( send_buff, NULL, 256);
   char userid[MAX_ID_SIZE+1];
   memset( userid, NULL, MAX_ID_SIZE+1 );
   CUser* pUser = NULL;

   usercount = GetShort( pBuf, index );
   if( usercount >= 25 || usercount < 0) return;
   
   SetByte( send_buff, WIZ_FRIEND_REPORT, send_index );
   SetShort(send_buff, usercount, send_index);

   for (int k = 0 ; k < usercount ; k++) {
      idlen = GetShort( pBuf, index );
      if (idlen > MAX_ID_SIZE || idlen < 0)
      {
         SetShort(send_buff, strlen(userid), send_index);
         SetString( send_buff, userid, strlen(userid), send_index );
         SetShort(send_buff, -1, send_index);
         SetByte( send_buff, 0, send_index);
         continue;
      }
      GetString( userid, pBuf, idlen, index );

      pUser = m_pMain->GetUserPtr(userid, 0x02);

      SetShort(send_buff, idlen, send_index);
      SetString( send_buff, userid, idlen, send_index );

      if (!pUser)
      {
         SetShort(send_buff, -1, send_index);
         SetByte(send_buff, 0, send_index);
      }
      else
      {
         SetShort(send_buff, pUser->m_Sid, send_index);
         if (pUser->m_sPartyIndex >= 0)
         {
            SetByte(send_buff, 3, send_index);
         }
         else
         {
            SetByte(send_buff, 1, send_index);
         }
      }
   }

   Send(send_buff, send_index);
}

So we can glean from the above code a couple of notable things:

  • The total number of players retrieved and placed back in that packet (with statuses) can be no more than 25.
  • The buffer needs to be approximately: 1 (opcode) + 2 (user count; from memory this isn't used anymore, but it doesn't hurt to have slightly extra) + (25 [player limit] * (2 [string size prefix] + MAX_ID_LEN [20] + 1 [status byte])) bytes in length. As there's 25 users total, that's 578 bytes. MGame's is 256 - clearly, it's not big enough.


There's really two different solutions here (at least, to solve the crash exploit) of which I both explained in a previous thread (in the old Snoxd) when encouraging you guys to figure out a patch for yourself. However, I am a little bit disappointed you chose the latter - the latter being to simply decrease the player limit. That limits functionality! The other method really isn't so hard, so here it is - done for you:

This solution means we need to increase the array! To do that, we need to adjust the stack space allocated for that function and fix up all required references that follow.

First things first - 578 in hexadecimal is 242h. Currently, they allocate:
Kod:
004B4B50    81EC 30010000  SUB ESP,130
30h of that is for the other variables they require in that method, so 100h (256!) is what they have assigned for our send_buff array. So, what we'll want to do is make it 272h (that is, 30h [other variables] + 242h [increased send_buff array]). However, since the stack pointer needs to be aligned, we will increase that ever-so-slightly to 280h. Wink

[size="5"]1.298[/size]

Increase the stack allocated for it:
Kod:
004B4B50    81EC 80020000  SUB ESP,280

Increase the memset() call's length parameter:
Kod:
004B4B5C    68 42020000    PUSH 242

Increase the offset of the first reference used (for the initial memset() call):
Kod:
004B4B61    8D85 8EFDFFFF  LEA EAX,DWORD PTR SS:[EBP-272]

Fix up all of the other references:
Kod:
004B4BA5    8D85 90FDFFFF  LEA EAX,DWORD PTR SS:[EBP-270]
Kod:
004B4BAB    C685 8EFDFFFF >MOV BYTE PTR SS:[EBP-272],49
Kod:
004B4BB3    889D 8FFDFFFF  MOV BYTE PTR SS:[EBP-271],BL
Kod:
004B4C1C    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
004B4C33    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
004B4C63    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
004B4C78    888435 8EFDFFF>MOV BYTE PTR SS:[EBP+ESI-272],AL
Kod:
004B4C92    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
004B4CB1    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
004B4CC9    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
004B4CDB    80A435 8EFDFFF>AND BYTE PTR SS:[EBP+ESI-272],0
Kod:
004B4CF2    8D85 8EFDFFFF  LEA EAX,DWORD PTR SS:[EBP-272]

[size="5"]1.310/1.351/2.0[/size]

Increase the stack allocated for it:
Kod:
0049581E    81EC 80020000  SUB ESP,280

Increase the memset() call's length parameter:
Kod:
0049582A    68 42020000    PUSH 242

Increase the offset of the first reference used (for the initial memset() call):
Kod:
0049582F    8D85 8EFDFFFF  LEA EAX,DWORD PTR SS:[EBP-272]

Fix up all of the other references:
Kod:
00495873    8D85 90FDFFFF  LEA EAX,DWORD PTR SS:[EBP-270]
Kod:
00495879    C685 8EFDFFFF >MOV BYTE PTR SS:[EBP-272],49
Kod:
00495881    889D 8FFDFFFF  MOV BYTE PTR SS:[EBP-271],BL
Kod:
004958EA    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
00495901    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
00495931    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
00495946    888435 8EFDFFF>MOV BYTE PTR SS:[EBP+ESI-272],AL
Kod:
00495960    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
0049597F    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
00495997    8D8435 8EFDFFF>LEA EAX,DWORD PTR SS:[EBP+ESI-272]
Kod:
004959A9    80A435 8EFDFFF>AND BYTE PTR SS:[EBP+ESI-272],0
Kod:
004959C0    8D85 8EFDFFFF  LEA EAX,DWORD PTR SS:[EBP-272]

...and you're done! We didn't have to compromise functionality for it, either. Smile
[/quote]


Hello Kitty
vs
eMoStyLe



avatar
Hello EMO
EMO Team
EMO Team

Cinsiyet : Erkek
Burçlar : Yay
Yılan
Mesaj Sayısı : 935
Puan : 250643
Rep Puanı : 18
Doğum tarihi : 28/11/89
Kayıt tarihi : 21/07/09
Yaş : 27
Nerden : EMO WorlD
İş/Hobiler : RCE Student / Game Hacking / Learn Beginner C#,C++,Delphi
Lakap : EMO

Kullanıcı profilini gör http://emostyle.myforumpro.com

Sayfa başına dön Aşağa gitmek

Önceki başlık Sonraki başlık Sayfa başına dön


 
Bu forumun müsaadesi var:
Bu forumdaki mesajlara cevap veremezsiniz