برچسب Archives: kernel

آنالیز ساختار ویندوز و روت کیت های سطح هسته-بخش پایانی

اگر کمی با برنامه نویسی کرنل آشنایی داشته باشید، حتما ساختار DRIVER_OBJECT را به خوبی می شناسید. این ساختار دارای فیلدی به نام MajorFunction است که آرایه ای از نوع PDRIVER_DISPATCH که آدرس روتین های مدیریت IRP دریافتی را در خود نگهداری می کند. IRP ها در wdm.h تعریف گردیده اند، نمیخواهیم وارد مبحث برنامه نویسی سطح کرنل شویم پس بیشتر وارد جزییات نمی شویم. اگر بتوانیم به ساختار DRIVER_OBJECT یک درایور دسترسی پیدا کنیم می توانیم عمل هوک را برای IRP های دریافتی آن انجام دهیم و IRP های آن درایور را مشاهده نماییم. ساده ترین راه برای دسترسی به این ساختار استفاده از تابع IoGetDeviceObjectPointer() است. این تابع آدرس Device Object را به عنوان خروجی بر میگرداند و درواقع Driver Object فیلدی از Device Object است.ساختار Device_Object ها را در تصویر زیر میبینیم:

Device_Object

همانگونه که مشاهده می کنیم فیلد NextDevice به دیوایس بعدی اشاره می کند وقتی درایورها به هم متصل شده اند و یک chain تشکیل دهند می توان مقادیر آن را مشاهده نماییم.  هر DeviceObject دارای DriverObject خودش می باشد که در فیلد DriverObject مشخص گردیده است. برای مشاهده درایورها می توانیم از کامند !object \device\ استفاده نماییم که لیستی از کل آبجکت ها را نشان می دهد. سپس برای نمایش استک از کامند  !devstackمی توانیم استفاده نماییم.

اطلاعات بیشتر

آنالیز ساختار ویندوز و روت کیت های سطح هسته-بخش سوم

در ادامه بحث های مطرح شده در آنالیز ساختار ویندوز و روت کیت های سطح هسته-بخش اول  و همچنین آنالیز ساختار ویندوز و روت کیت های سطح هسته-بخش دوم ادامه بحث را دنبال خواهیم کرد.

یکی دیگر از تکنیک های که روت کیت ها استفاده می نمایند درواقع می توان گفت نسل جدیدتر روت کیت ها، استفاده از تکنیک DKOM[1] نام دارد. در این تکنیک ساختار های کرنل را تغییر میدهیم . ساختارهایی مانند لیست پروسه های فعال ، درایورها.

در این روش هیچگونه هوک و یا تغییری در جداولی مانند SSDT,IDT انجام نمیدهیم. روت کیت ها می توانند با Unlink نمودن یک شی EPROCESS از ActiveProcesLinks خود را پنهان نمایند و پروسه ای را از دید تابع ZwQuerySystemInformation() که برای بدست آوردن لیست پروسه های اجراشده در سیستم استفاده می نماییم پنهان نماید. کرنل از ساختاری به نام KPCR[2] استفاده می کند. در این ساختار اطلاعات مهم و اساسی مانند IDT ، GDT و … ذخیره می شود. برای دسترسی راحتتر به KPCR کرنل آدرس آن را در نسخه های x86 ویندوز درون رجیستر fs و همچنین در ویندوزهای x64 در رجیستر gs ذخیره می کند. KPCR شامل ساختاری است به نام KPRCB[3] است. KPCR مستند شده است ولی KPRCB یک ساختار خصوصی است و تنها در ntoskrnl مورد استفاده قرار می گیرد. این ساختار شامل اطلاعات درباره Scheduling پروسه ها می باشد.

Kernel processor control region

در ساختار _KPRCB فیلدی به نا م CurrentThread وجود دارد که برایمان مهم می باشد همانطور در تصویر زیر می بینیم این فیلد از نوع ساختار _KTHREAD است:

kernel processor control block

برای مشاهده محتوای ساختارهای KPCR و KPRCB می توانیم از دستور های !pcr و !prcb استفاده نماییم، مقدار Current  را به یاد داشته باشید.

pcr-command-windbgاطلاعات بیشتر

آنالیز ساختار ویندوز و روت کیت های سطح هسته-بخش دوم

در ادامه بحث های مطرح شده در آنالیز ساختار ویندوز و روت کیت های سطح هسته-بخش اول  ادامه بحث را دنبال خواهیم کرد.

سطح هسته همانند سطح کاربر دارای هوک های خاص خودش است که معروفترین آن ایجاد تغییرات دلخواه در جداولی است که آدرس توابع مورد نیاز سیستم را در خود نگهداری می کنند:

  • System Service Dispatch Table (SSDT)
  • Interrupt Descriptor Table (IDT)

آدرس توابع سطح کرنل درون جدول SSDT نگهداری می شود(توابع nt*). هنگامیکه روند اجرا یک برنامه سطح کاربر میخواهد به سمت کرنل هدایت شود  ID مرتبط با تابع کرنل درون رجیستر EAX قرار می گیرد و رجیستر EDX به لیست پارامترهای که بایستی به تابع ارجاع داده می شود اشاره می کند، سپس با اجرای دستور int 2e و یا sysenter روند اجرا پروسه به سطح کرنل خواهد رفت.  هنگامیکه وقفه ای رخ می دهد سیستم عامل با جستجو در IDT ، روتین مرتبط با مدیریت آن وقفه را بدست میاورد. این جدول تمامی وقفه ها را درون خود نگهداری می کند. روتین هندل کننده وقفه 0x2e  تابع KiSystemService() از ntoskrnl است. برای بازگشت به سطح کاربر از دستور iret استفاده می شود. در صورتی که از دستور sysenter استفاده شود برای بازگشت به سطح کاربر از دستور sysexit استفاده خواهد شد. برای پشتیبانی از دستور sysenter ویندوز در زمان بوت آدرس روتین مرتبط را بجای IDT در رجیستر  MSR[1]  ذخیره می کند. . اسکریپت زیر را می توانید از این آدرس[2] دریافت نمایید. با دستور زیر در windbg میبینیم که handler این وقفه تابع  KiSystemService() است :

اطلاعات بیشتر

آپدیت هسته ویندوز بعد از 9 سال در ویندوز 10 کمی در مورد این چگونگی تکامل این ویندوز

مقدمه

 

انتشار ویندوزی به نام ویندوز 10 همه رو شگفت زده کرد البته اول به دلیل نام گذاری عجیب غریب مایکروسافت که یهو از روی 8.1 سویچ کرده روی 10 البته این مسائله که ویندوزی به نام 8.1 وجود نداره و فقط تغییرات بوده رو در ادامه توضیح میدیم ولی این نام گذاری در نوع خودش کم نظیر  بود و در جایگاه دوم این که عرضه این نسخه برعکس نسخه های قبلی که گرون تر از قبل می کرد رایگان برای مدتی در نظر گرفت و مورد بعدی که من مستند نخوندم ولی بارها شنیدم که میگفتن که ویندوز 10 آخرین نسخه ویندوز خواهد بود در آخرین چیزی که منو شگفت زده کرد آپدیت هسته ویندوز برای منی که به معماریش دقت می کنم شگفت زده ام کرد علت رو میگم وگرنه منگول نیستم 😀

 

442994-windows-10

تاریخچه ای از ویندوز از نگاه من

(این قسمت در قالب خاطره مقدمه ای هست برای ادامه یادداشت)

 

در زمانی که ویندوز xp رو نصب می کردیم کلی حال می کردیم یه بار رفتم پیش یکی از دوستام دیدم روی سیستم یه ویندوز خیلی خیلی خوشگل ( البته برای اون موقع) هستش گفتم اسمش چیه این؟ با غرور تمام گفت: LongHorn…

واااای هنوز نمیتونم فراموش کنم چقدر حسرت نصب این ویندوز توی دلم موند و چقدر دنبالش گشتم، آخه اون موقع سیستمم کشش نداشت ( گرافیک ۶۴ مگ و اینا میخواست) و بعدش دیگه ویستا اومده بودش و ماجرا پیش رفت.

آره خلاصه در حسرت لانگ هورن بسی سوختیم و اما مایکروسافت در پی تجربه ای که xp داشت به این نتیجه رسیده بودش خوشگل کردن ویندوز تنها دلیل کوچ کردن کاربران از ویندوز های قبلی به بعدی هستش.

اما متاسفانه در یک حرکت جالب لانگ هورن رو تو نطفه خفه کرد و در نهایت اشتباه جدید رو مرتکب شد اونم این بودش به کاربری ویندوز فکر نکرد فقط ظاهرش رو ساخت یعنی همون خروس قندی داد دست دنیا که اسمش Vista بودش ولی هرگز توجه دنیا به آن جلب نشد، و مهم ترین دلیل هاش چیزی به ناماطلاعات بیشتر