لینوکس یک سیستم‌عامل متن باز است و این موضوع به این معنی است که شما می‌توانید کد آنرا دریافت کرده، تغییر داده و تست کنید. اینکار به شما کمک می‌کند که از جزئیات طرز کار سیستم‌عامل اطلاع پیدا کرده و ساختارهای داخلی سیستم‌عامل را بررسی کرده و به دنیای جذاب #SystemProgramming وارد شوید. یکی از مراحلی که در نوشتن هر برنامه‌ای لازم بوده و هر برنامه نویسی درگیر آن می‌شود، #debug کردن است. یکی از ابزارهای قدرتمند برای دیباگ برنامه‌ها #gdb‌ است که قبلا معرفی شده و مقدمات کار با آن برای trace کردن برنامه‌های C معرفی شده است. برای trace کد کرنل لینوکس #kgdb مورد استفاده قرار می‌گیرد که با بکارگیری gdb به عنوان debugger امکان بررسی کد #kernel را فراهم می‌کند. در این ویدئو ما با معرفی #LinuxKernel شروع کرده و ابتدا ساده‌ترین راه برای کامپایل کردن آنرا آموزش می‌دهیم. سپس کدی ساده به یک #SystemCall اضافه کرده و اجرا شدن آنرا بررسی می‌کنیم. در نهایت شیوه‌ی فعال کردن kgdb برای کرنل جدید و استفاده از آن برای بررسی کد کرنل به کمک gdb نمایش داده می‌شود.

https://aparat.com/v/uL1Pi
==============
http://telegram.me/OxAA55/57

این ویدئو یکی از جلسات درس آزمایشگاه سیستم‌عامل در دانشگاه علم و صنعت است که در آن اتفاقاتی که از زمان روشن شدن کامپیوتر تا بارگذاری #Kernel لینوکس و آماده‌ی اجرا شدن سیستم‌عامل #Linux رخ می‌دهد شرح داده می‌شود. ابتدا به معرفی کارکرد BIOS پرداخته و ساختار حافظه و تفاوت Real Mode‌ و Protected Mode ذکر شده، سپس به بیان بخش‌های مختلف #MBR و شیوه‌ی نگهداری اطلاعات #Partitions و Bootloader سطح اول می‌پردازیم. در مرحله‌ی بعدی کاربرد #Grub و شیوه‌ی مشخص کردن کرنل لینوکس در آن بیان شده و پس از آن پروسه‌ی #init و طریقه‌ی اجرا شدن آن برای شروع بکار سیستم‌عامل در سطح هسته و User شرح داده می‌شود. در آخر #RunLevel های لینوکس و کاربرد هرکدام بیان شده و اشاره‌ای به #systemd نیز می‌شود. برای حسن ختام کار نیز یک نمونه از کد #Assembly برای نوشتن یک #Bootloader ساده و اجرای آن در qemu نمایش داده می‌شود.

https://www.aparat.com/v/I7JYW
==============
https://t.me/OxAA55

همراهان عزیز سلام
از آخرین پست من مدت زمان زیادی می‌گذره و متاسفانه مدت مدیدی به دلیل مشغله‌های مختلف نتونستم پستی منتشر کنم. چندماهی هست که داشتم روی آماده‌سازی و انتشار ویدئو در زمینه‌ی Windows Internals با رویکرد برنامه نویسی کار می‌کردم و خوشبختانه بخش اول ویدئوها که در مورد نخ‌ها توی WinAPI و کرنل ویندوز هست امروز منتشر شد. ویدئوهای منتشر شده سه مبحث رو پوشش میده:
۱. نوشتن برنامه چندنخی به کمک WinAPI
۲. استفاده از Thread Poolهایی که پروسه‌های ویندوزی دارند
۳. رفتن به دل کرنل ویندوز و ایجاد نخ در دل کرنل

اگر LinkedIn دارید لطفا اونجا من رو دنبال کنید و اگر هم ندارید می‌تونید به لیست پخش دوره از لینک زیر دسترسی پیدا کنید:
#windows #internals #system #kernel #programming #threads

https://www.aparat.com/playlist/1599634

تجربه‌ی تولید محتوا در مورد Windows Internals‌ و تغییر روند با دریافت بازخوردها

از اواخر سال ۱۴۰۰ شروع به ضبط ویدئو در مورد Windows Internals کردم و از بهار امسال انتشار ویدئوها رو شروع کردم. در این روند دوستانی بهم بازخورد دادند و برخی مواقع مواردی رو توصیه کردند که به کیفیت ارائه‌ها کمک می‌کرد که از همگی ممنونم. یک مشکلی که برخی از دوستان ذکر کردند این بود که روند ویدئوها یکم یکنواخت بوده و مثال‌ها ساده بودند. برخی مواقع هم توصیه‌ها در مورد اضافه کردن یکسری مطالب بودند که باعث شد یک فصل Debug اضافه کنم ولی در مجموع روند برای خودم هم دلپذیر نبود.

همزمان یک اتفاق خوبی که امسال در شرکت مهسان رخ داد اضافه شدن یک بخش آموزش به HR با مسئولیت محمدرضا واحدی عزیز بود که سعی داره مطالبی که برای همکاران می‌تونه به صورت مستقیم یا غیر مستقیم مفید باشه رو در قالب کلاس و ارائه برگزار کنه تا همکاران از بحث آموزش و تقویت خودشون غافل نشند. این بود که بازخورد ایشان رو هم گرفتم و از کمکشون استفاده کردم تا اگر میشه یکسری ارائه در مورد Internals ویندوز و لینوکس و موارد دیگه در شرکت داشته باشیم که پویایی بیشتری وجود داشته باشه و مستقیم بتونم از همکاران هم بازخورد بگیرم.

این شد که مسیر به ارائه‌هایی با عنوان Internals Sessions رسید که در هر جلسه از اون یک موردی به صورت نسبتا عمیق در ویندوز و لینوکس بررسی بشه. به این شکل همزمان میشه یک مقایسه‌ای هم بین معماری این دو سیستم‌عامل داشته و یک موضوع رو بهتر درک کرده و با توجه به Open Source بودن لینوکس بررسی کد رو هم انجام داد.

همچنین لازمه از آقای میلادسلیمی جهت طراحی بنر ارائه‌ها و آقای محمدمهدی عسکرزاده جهت آماده‌سازی محیط ضبط تشکر کنم.

در ادامه می‌تونید اولین جلسه ارائه در مورد System Calls در لینوکس را مشاهده کنید. در این ارائه مطالب زیر توضیح داده شده‌اند:
• کامپایل و راه‌اندازی لینوکس با QEMU
• بررسی syscall‌در usermode به کمک strace
• بررسی syscall در kernel به کمک ftrace
• دیباگ کرنل با gdb
• اضافه کردن syscall به لینوکس
• شیوه‌ی ارسال پارامترهای syscall به کرنل
• بررسی راه‌اندازی syscall و رجیستر MSR_LSTAR
• جزئیات دستور syscall در اینتل
• شیوه‌ی پردازش syscall در کرنل
• بررسی کردن sys_call_table در gdb

لینک ارائه در یوتیوب:
https://youtu.be/1LBiSh-C9WU
لینک ارائه در آپارات:
https://www.aparat.com/v/Bn2Yf

#windows #linux #internals #kernel #gdb #debugging #syscall #programming #ftrace #strace #qemu

انتشار جلسه دوم Internals Sessions و خاتمه ارائه‌های سال ۱۴۰۱

این ویدئو دومین جلسه از ارائه‌های Internals Sessions است که در هر قسمت آن به بررسی موضوعی در ویندوز یا لینوکس می‌پردازیم. در این ارائه ابتدا در مورد ابزارهایی که برای بررسی سیستم‌عامل ویندوز استفاده می‌شوند صحبت کرده و شیوه‌ی استفاده از Process Explorer/Process Monitor نمایش داده می‌شود. سپس به شرح نحوه‌ی استفاده از WinDbg برای دیباگ برنامه‌ها و کرنل ویندوز پرداخته و قرارداد فراخوانی توابع در مدل 64بیتی نمایش داده می‌شود. در انتها نیز چرخه‌ی اجرای توابع ویندوز و رسیدن درخواست به کرنل و پردازش System Call شرح داده شده و به کمک WinDbg بررسی می‌شود. ارائه با نمایش فراخوانی سیستمی به صورت مستقیم و عدم استفاده از لایه‌ی ntdll.dll به پایان می‌رسد.

جزئیات مطالبی که در این ارائه بررسی می‌شوند به شرح زیر هستند:
• مرور User/Kernel Modes و حافظه‌ی مجازی
• معرفی ابزارهای SysInternals
• نمایش اطلاعات Process/Thread با Process Explorer
• معرفی Handle و کاربرد آن
• نمایش رویدادهای پروسه و APIهای اجرا شده با Process Monitor
• معرفی WinDbg، انواع دستورات آن و کاربرد Symbols
• مرور Calling Conventions در مدل ۶۴بیتی و بررسی آن در WinDbg
• فعال کردن Debugging‌در ویندوز
• اتصال WinDbg به کرنل ویندوز از طریق شبکه
• معرفی EPROCESS
• چرخه‌ی طی شده برای WinAPIs از User Mode‌ تا Kernel
• جزئیات اجرای دستور syscall و رجیستر MSR_LSTAR
• مروری بر پیاده‌سازی CreateFile در ReactOS
• شرح ساختار System Service Table (KiServiceTable)
• بررسی CreateFile از User Mode‌ تا کرنل و رسیدن به syscall‌ از روی KiServiceTable
• اجرای مستقیم CreateFile با فراخوانی سیستمی بدون ntdll

لینک ارائه در یوتیوب و آپارات:
https://youtu.be/_dJPXsfnx3U
https://aparat.com/v/C7xIE
لینک کانال من در تلگرام:
https://t.me/OxAA55

#windows #internals #kernel #windbg #syscall #programming #debugging

این ویدئو سومین جلسه از سری Internals Sessions است. در هر جلسه از این سری، ما یک موضوع مرتبط با ویندوز یا لینوکس را مورد بررسی قرار داده و شیوه پیاده‌سازی و عملکرد آن بخش را توضیح می‌دهیم. در این جلسه، ماژول‌های کرنلی در لینوکس را مورد بررسی قرار داده و ساختار آن‌ها، روش نوشتن ماژول‌ها و افزودن قابلیتی به کرنل لینوکس را بررسی می‌کنیم.

پس از آشنایی با ماژول‌های کرنلی، به بررسی procfs می‌پردازیم و نحوه اضافه کردن یک فایل در /proc و نمایش اطلاعات پروسه‌ها با استفاده از آن را بررسی می‌کنیم. سپس به بررسی ساختار و روش اضافه کردن character device، استفاده از major/minor و اضافه کردن فایل device با استفاده از mknod و ارتباط با ماژول می‌پردازیم. در انتهای ارائه، به نوشتن rootkit و hook کردن توابع کرنل با استفاده از ftrace و تغییر سطح دسترسی کاربر عادی و root کردن آن می‌پردازیم.

برای پشتیبانی و رساندن مطالب به دست علاقه‌مندان لطفا این پست را بازنشر کنید.

مواردی که در این ارائه بررسی می‌شوند به صورت جزئی به صورت زیر هستند:
• Kernel Modules Introduction
• Modules Structure and Makefile
• Modules Parameters
• Commands for Working with Modules
• Modules Dependecy and Exported Functions
• Virtual Filesystem Introduction
• Procfs Introduction
• Procfs Programming
• Character Devices and Major/Minor Numbers
• Character Devices Programming
• Kernel Rootkits
• Ftrace Hooking
• Privilege Escalation Using Kernel Modules
• Hiding Kernel Modules

لینک ارائه در آپارات:
https://www.aparat.com/v/MBrNY
لینک ارائه در یوتیوب:
https://youtu.be/AqVEnLIqeI8

#linux #internals #kernel #programming #ftrace #hooking #rootkit #hook #internalssessions #kernelmodules

انتشار جلسه چهارم Internals Session‌: برنامه نویسی کرنلی در ویندوز با پیاده‌سازی یک Rootkit

این ویدئو چهارمین جلسه از سری Internals Sessions است. در هر جلسه از این سری، ما یک موضوع مرتبط با ویندوز یا لینوکس را مورد بررسی قرار داده و شیوه پیاده‌سازی و عملکرد آن بخش را توضیح می‌دهیم. در این جلسه، ماژول‌های کرنلی در ویندوز را مورد بررسی قرار داده و ساختار آن‌ها، روش نوشتن ماژول‌ها و افزودن قابلیتی به کرنل ویندوز را بررسی می‌کنیم.

در این ویدئو ابتدا به بررسی ساختار درایورها در کرنل ویندوز پرداخته و شیوه‌ی نوشتن یک درایور برای آنرا بررسی می‌کنیم. سپس به بررسی شیوه‌ی استفاده از لیست‌های پیوندی در کرنل ویندوز پرداخته و شیوه‌ی نگهداری اطلاعات پروسه‌ها در لیست پیوندی را معرفی می‌کنیم. در ادامه ساختار توکن و مجوز دسترسی پروسه‌ها بررسی شده و در نهایت به پیاده‌سازی یک درایور برای مخفی کردن پروسه‌ها و افزایش دسترسی آن‌ها می‌پردازیم. در این حین با جزئیات ارتباط با درایور و ساختار IRP نیز آشنا می‌شویم.

لطفا برای پشتیبانی و رساندن مطالب به دست علاقه‌مندان این پست را بازنشر کنید.

مواردی که در این ارائه بررسی می‌شوند به صورت جزئی به صورت زیر هستند:
• Kernel Modules Introduction
• Windows Driver Models
• Windows Driver Frameworks
• Anatomy of a Driver
• Driver and Device Objects
• I/O Request Packets
• Driver Signing & Test Mode
• Kernel Doubly-Linked Lists
• EPROCESS & ActiveProcessLinks
• Token Stealing
• Hiding Processes
• Writing a Rootkit
• Patch Guard
لینک ارائه در یوتیوب:
https://youtu.be/hN0RZ5Oup-c
لینک ارائه در آپارات:
https://www.aparat.com/v/VLXRh

#windows #internals #kernel #programming #irp #driver #eprocess #token #windbg #internalssessions #kernelmodules

شیوه‌ی دریافت حافظه توسط برنامه‌ها و درایورها در ویندوز

در پست قبلی در مورد حافظه‌ی مجازی در ویندوز صحبت کردیم و وظایف این لایه و پارامترهایی که در ابزارهای مختلف برای بررسی میزان حافظه‌ی تخصیص داده شده به پروسه‌ها وجود دارند را مرور کردیم. در این پست جزئیات دریافت حافظه از ویندوز توسط برنامه‌ها و درایورها را شرح داده و این فرآیند را در سمت کرنل عمیق‌تر بررسی می‌کنیم.

در user mode چند لایه API برای دریافت حافظه از سیستم‌عامل ویندوز وجود دارد. در پایین‌ترین سطح، APIهای VirtualAlloc وجود دارند که هیچ‌گونه مدیریتی بر روی حافظه‌ی دریافت شده انجام نداده و حافظه را در واحد‌هایی به اندازه‌ی Page (پیش‌فرض 4KB) تخصیص می‌دهند. این APIها امکان reserve/commit کردن حافظه را فراهم کرده و برای کار با حافظه‌های بزرگ مناسب هستند.

لایه‌ی بعدی APIهای حافظه که برای کار با اندازهای کوچک حافظه مثل چندبایت نیز مناسب است Heap می‌باشد. این APIها به صورت داخلی از APIهای لایه‌ی قبلی استفاده کرده و نیازی به تخصیص حافظه در ابعاد Page را ندارند. بر روی این لایه است که زبان‌هایی مثل C/C++ پیاده‌سازی‌های malloc/new و free/delete را انجام می‌دهند (جزئیات پیاده‌سازی وابسته به کامپایلر است) که مربوط به پیاده‌سازی‌های Compilerها می‌باشد. در این لایه دیگر APIهای ویندوز مستقیم توسط برنامه‌نویس استفاده نشده و نیازی به کار با آن‌ها ندارد.

اما در سمت کرنل ماجرا از چه قرار است؟ در سمت کرنل چیزی با عنوان VirtualAlloc/Heap وجود ندارد و به درایورها حافظه از طریق دو نوع Pool اختصاص داده می‌شود. اولین نوع Non-Paged Pool است که حافظه‌ی تخصیص داده شده از آن تضمین می‌شود که همیشه در RAM باشد. این موضوع برای جلوگیری از Deadlock و Crash کردن درایور اهمیت دارد (جزئیات این موضوع بماند برای یک پست و ویدئوی دیگر!) نوع دوم Pool که حافظه‌ی آن ممکن است در RAM نبوده و به دیسک منتقل شود Paged Pool است.

در این ویدئو جزئیات تخصیص حافظه در سمت کرنل و APIهای ExAllocatePool بررسی شده، در یک درایور تخصیص و آزاد شدن حافظه نمایش داده شده و سپس به کمک WinDbg حافظه‌ی تخصیص داده شده به درایور بررسی می‌شود.

لینک ویدئو در یوتیوب:
https://youtu.be/pMPyT13jzwk
لینک ویدئو در آپارات:
https://aparat.com/v/VIvgR

#ShortWinInternals #windows #memory #internals #VirtualMemory #MemoryCounters #kernel #drivers #SystemPools #WinDbg

مقدار صفر برای argc در برنامه‌های لینوکسی. چرا و چگونه؟

همه چیز از بررسی CVE-2021-4034 و کامپایل مجدد PolKit بر روی Ubuntu 22.04 شروع شد! تصمیم داشتم یک نسخه‌ی آسیب‌پذیر PolKit رو با فعال کردن Debug Symbols کامپایل کرده و مراحل کامل این CVE رو در GDB بررسی کنم. به صورت خلاصه بگم که این آسیب‌پذیری در باینری pkexec وجود دارد و به کمک آن می‌توان LPE انجام داد. یکی از شرایط استفاده از این آسیب‌پذیری این است که در زمان اجرای pkexec شرط argc==0 برقرار باشد که از طریق آن متغیرهای محلی خوانده شده و بتوان یک library مخرب را بارگذاری نمود.

از آنجایی که pkexec علاوه بر لینوکس بر روی Solaris, BSD هم قابل استفاده است، در مقاله‌ی اصلی این CVE که توسط Qualys Security منتشر شده است متن زیر مشاهده می‌شود که از الزام argc==0 برای امکان‌پذیر بودن این LPE خبر می‌دهد.
OpenBSD is not exploitable, because its kernel refuses to execve() a program if argc is 0

پس فرض من این بود که در نسخه‌های اخیر لینوکس هم با کامپایل PolKit باید بتوان این آسیب‌پذیری را تست کرد. این بود که بر روی Ubuntu 22.04 یک نسخه‌ی آسیب‌پذیر را کامپایل کرده و یک کد ساده به صورت زیر نوشتم که pkexec را اجرا کرده و argc==0 برقرار باشد.

void main() {
char *args[] = { NULL };
char *envs[] = {"SHELL=/bin/bash", 0};
execve("pkexec", args, envs);
}

با اجرای برنامه و زدن strace مشاهده شد که فراخوانی در سطح user طبق انتظار انجام شد.
execve("pkexec", [], 0x7ffe3883b200 /* 1 var */)

ولی دو تا مورد عجیب رخ داد. اول اینکه برنامه در gdb بر خلاف انتظار با argc==1‌ اجرا شده و argv[0] که اسم برنامه در آن قرار می‌گیرد و طبق مدل فراخوانی باید NULL می‌بود برابر “” شده بود. مورد دومی که عجیب بود پیام زیر در dmesg بود.
process 'exploit' launched 'pkexec' with NULL argv: empty string added

با رسیدن به این مرحله به سراغ Ubuntu 20.04 رفتم و همین کد را بر روی آن اجرا کردم که همه چیز طبق انتظار رخ داده و در gdb با رسیدن به main برنامه‌ی pkexec مقدار argc==0 برقرار بوده و امکان تست CVE وجود داشت. اینجا واضح بود که در کرنل‌های جدید لینوکس در فراخوانی سیستمی execve تغییراتی اعمال شده است که جلوی اجرای برنامه‌ها با argc==0 گرفته شود. اینجا دیگه لازم بود کد کرنل چک شود!

با رفتن به github‌ و بررسی فایل fs/exec.c کرنل لینوکس مشاهده شد که در تابع اجرای فراخوانی سیستمی execve کد زیر در March 2022 اضافه شده که جلوی اجرای برنامه‌ها با argc==0 را می‌گیرد.

/*
* When argv is empty, add an empty string ("") as argv[0] to
* ensure confused userspace programs that start processing
* from argv[1] won't end up walking envp. See also
* bprm_stack_limits().
*/
if (bprm->argc == 0) {
retval = copy_string_kernel("", bprm);
if (retval < 0)
goto out_free;
bprm->argc = 1;
}

پس از این به بعد علاوه بر OpenBSD بر روی لینوکس نیز امکان اجرای آسیب‌پذیری‌های این مدلی وجود نخواهد داشت! :-D
پ.ن: در آینده‌ یک ویدئو از شیوه‌ی کامل اجرای این CVE منتشر می‌کنم.

#linux #kernel #CVE #PolKit #pkexec #execve

جزئیات پروسه و نخ در لینوکس

به صورت خلاصه از دید ویندوز پروسه فقط یک container می‌باشد که اجرا نشده و فضایی برای اجرای Threadها فراهم می‌کند و در سطح کرنل نیز دو ساختار EPROCESS, ETHREAD برای این دو تعریف شده‌اند. اما در لینوکس ماجرا متفاوت است و Process, Thread هر دو قابلیت اجرا داشته و در سطح کرنل نیز یک ساختار task_struct برای آن‌ها تعریف شده است. در دنیای شی‌گرایی مثل این است که در لینوکس یک کلاس برای این دو وجود دارد و فقط در زمان ایجاد شی خصوصیات متفاوتی برای آن‌ها تنظیم می‌شود.

اگر به سراغ برنامه‌نویسی سیستمی در لینوکس برویم، تابع fork برای ایجاد پروسه استفاده شده و از تابع pthread_create نیز برای ایجاد نخ در لینوکس استفاده می‌شود. در سطحی کمی پایین‌تر، هر دوی این توابع syscallای به نام clone را فراخوانی می‌کنند و با ست‌کردن فلگ‌هایی مشخص می‌کنند که قصد ایجاد پروسه یا نخ را دارند. در زمان بررسی برنامه‌ها، در خروجی دستور ps برای یک برنامه‌ی چند پروسه‌ای pidهای مختلفی خواهیم دید ولی در یک برنامه‌ی چند نخی pidها یکسان بوده ولی عددهای متفاوتی در فیلد Light-Weight Process-LWP می‌بینیم.

نکته‌ی جالب دیگر این است که در سطح کرنل پروسه‌ها یک لیست پیوندی تشکیل می‌دهند. هم شیوه‌ی ایجاد لیست پیوندی Generic در سطح کرنل و در زبان C موضوع جالبی است و هم اینکه به کمک فیلدی به اسم tasks می‌توانیم یک لیست پیوندی از پروسه‌ها تشکیل دهیم که به پروسه‌های قبلی و بعدی اشاره می‌کند.

این موارد و موارد دیگری از جزئیات پروسه‌ها و نخ‌های لینوکس مواردی هستند که در این ویدئو به آن می‌پردازیم.

لینک ویدئو در یوتیوب:
https://youtu.be/0fxYtyFn8Jc
لینک ویدئو در آپارات:
https://aparat.com/v/cnytp55

#ShortLinuxInternals #linux #internals #syscalls #kernel #process #thread #gdb #qemu #clone #LWP

استفاده از ftrace‌ برای بررسی توابع فراخوانی شده در کرنل لینوکس

به کمک دستور strace می‌توان system callهایی که در اجرای برنامه‌ها فراخوانی می‌شوند را بررسی نمود ولی امکان اطلاع پیدا کردن از توابعی که درون کرنل لینوکی فراخوانی می‌شوند وجود ندارد و به عنوان مثال نمی‌توان متوجه شد که در خواندن یک فایل، از چه توابعی در چه ماژولی و یا چه سیستم‌فایلی استفاده می‌شود.

لینوکس به کمک قرار دادن یکسری point در بخش‌هایی از کرنل، مکانیزمی به اسم ftrace فراهم می‌کند که مشابه procfs پس از mount شدن، با فراهم کردن یکسری فایل، امکان بررسی توابعی کرنلی که در رویدادهای مختلف فراخوانی می‌شوند را در اختیار قرار می‌دهد.

از ftrace در حالت‌های مختلفی می‌توان استفاده نمود. مثلا می‌توان فقط لیست توابعی که فراخوانی می‌شوند را مشاهده کرده و یا به صورت نمایش گرافی، کلیه‌ی توابعی که با شروع از یک تابع یکی پس از دیگری فراخوانی می‌شوند را دیده و به این صورت مثلا متوجه شد که پس از تابع vfs_read که یک تابع برای پردازش درخواست خواندن از فایل در VFS لینوکس است، به سراغ تابع خواندن از ext4 می‌رسیم یا xfs.

یکی از دیگر کاربردهای ftrace که هم در توسعه‌ی ابزارهای امنیتی کاربرد دارد و هم بدافزارها می‌توانند از آن استفاده کنند پیاده‌سازی hooking برای توابع کرنل لینوکس است. در این روش ftrace در ابتدای فراخوانی تابع کرنلی، به سراغ اجرای تابعی که شما مشخص کرده‌اید رفته و پس از اتمام کار تابع شما، می‌تواند به چرخه‌ی اصلی فراخوانی تابع کرنل بازگشته و آنرا تا انتها اجرا کند.

در این ویدئو کاربرد ftrace شرح داده شده و شیوه‌های مختلف استفاده از آن نمایش داده می‌شود.

لینک ویدئو در یوتیوب:
https://youtu.be/AhxxT7lal5c
لینک ویدئو در آپارات:
https://aparat.com/v/acmv35h

#ShortLinuxInternals #linux #internals #kernel #tracing #ftrace

سرقت توکن پروسه‌ها در ویندوز به کمک WinDbg

توکن یا به صورت کامل‌تر Access Token در ویندوز، یک شی است که شرایط امنیتی که یک پروسه یا نخ تحت آن می‌توانند کار کنند را مشخص می‌کند. توکن با احراز هویت موفق یک کاربر ایجاد شده و هر پروسه‌ای که توسط کاربر ایجاد شود، یک نسخه از آنرا خواهد داشت.

ویندوز از توکن در زمانیکه یک نخ تلاشی برای دسترسی به یک شی می‌کند استفاده می‌کند که کاربر را تشخیص داده و بررسی کند که آیا کاربر مجوز دسترسی به شی مورد نظر را دارد یا خیر. به عنوان مثال فرض کنید که با notepad قصد باز کردن یک فایل را داشته باشید. در این مثال پروسه‌ی notepad‌ توسط کاربر شما ایجاد شده و در نتیجه توکن آنرا خواهد داشت. شی مورد دسترسی نیز فایلی است که برای آن دسترسی خاصی تعریف شده و باید بررسی شود که آیا توکن مورد نظر مجوز دسترسی به فایل را دارد یا باید جلوی این دسترسی توسط ویندوز گرفته شود.

برخی از اطلاعاتی که توسط توکن مشخص می‌شوند عبارتند از: شناسه یا SID‌ کاربر. شناسه‌ی گروه‌هایی که کاربر عضوی از آن‌هاست. شناسه‌ی نشست جاری. لیستی از مجوزهایی که کاربر یا گروه‌های آن دارند.

یکی از کارهایی که با توکن‌ها قابل انجام بوده و در سرویس‌ها کاربرد زیادی دارد impersonation است. در این مدل، یک نخ با توکن متفاوتی از توکن اصلی خود اجرا شده و در نتیجه مجوزهای متفاوتی خواهد داشت. به عنوان مثال فرض کنید یک File Server دارید که فایل‌های آن محدودیت‌های دسترسی متفاوتی دارند. در این مثال، سرور با انجام impersonation درخواست هر کلاینت را با توکن همان کلاینت پاسخ داده و در نتیجه هر کاربر تنها به فایل‌های خود دسترسی خواهد داشت.

یکی از کارهایی که بدافزارها از آن بهره می‌برند همین بحث impersonation و دسترسی به منابع مختلف، مثل dump اطلاعات کاربران، است. در این حالت بدافزار توکن یک پروسه با دسترسی بالا را دزدیده و از آن برای مقاصد خود استفاده می‌کند.

در این ویدئو به کمک WinDbg مفهوم توکن و شیوه‌ی دزدیدن و قرار دادن آن بر روی پروسه‌ی دلخواهی شرح داده می‌شود که هم با موضوع توکن آشنا شده و هم به صورت عملی ببینیم که بدافزارها چطور می‌توانند از impersonation سواستفاده کنند.


لینک ویدئو در یوتیوب:
https://youtu.be/NTPVeauBDe4
لینک ویدئو در آپارات:
https://www.aparat.com/v/cvyprh5

#ShortWinInternals #windows #internals #token #WinDbg #impersonation #kernel

محدود کردن اجرای پروسه‌ها به کمک Sandbox در لینوکس

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

روش‌ها و ابزارهای مختلفی برای انجام Sandboxing بر روی لینوکس وجود دارد و برخی از این روش‌ها مستقیم توسط کرنل نیز پشتیبانی می‌شوند. به عنوان مثال در لینوکس به کمک namespaces امکان جداسازی سیستم‌فایل، شبکه و پروسه‌های سیستم از یکدیگر فراهم بوده و به کمک cgroups می‌توانیم محدودیت دسترسی به RAM/CPU تعریف کنیم، که ایجاد Containerها و استفاده از docker به لطف این موارد در لینوکس امکان‌پذیر است.

یک روش جالب دیگر برای ایجاد محدودیت اجرا در لینوکس seccomp است که خود یک System Call بوده و قابلیت محدود کردن System Callهایی که یک پروسه امکان اجرای آن‌ها را دارد فراهم می‌کند. این System Call به شیوه‌های مختلفی مثل تعریف محدودیت درون برنامه، اعمال محدودیت به کمک systemd و استفاده به صورت library و با ست کردن LD_PRELOAD قابل استفاده است.

در این ویدئو کاربرد Sandboxing توضیح داده شده و پس از معرفی چند روش انجام آن، جزئیات و نحوه‌ی استفاده و کاربرد seccomp در لینوکس نمایش داده می‌شود.

لینک ویدئو در یوتیوب:
https://youtu.be/g8fuUag7oA8
لینک ویدئو در آپارات:
https://aparat.com/v/wowkca1

#ShortLinuxInternals #linux #internals #kernel #programming #seccomp #sandbox #namespaces #syscalls #processes #systemd

سیگنال و وضعیت پروسه‌ها در لینوکس

در لینوکس برای ارسال یک رویداد یا اطلاع دادن یک رخداد به پروسه‌ها می‌توان از سیگنال استفاده نمود. شیوه‌ی کار به این صورت است که پروسه در صورت دریافت سیگنال، اجرای کد اصلی خود را متوقف کرده و به سراغ پردازش Signal می‌رود. از همین روی در لینوکس به سیگنال Asynchronous Event و یا Soft Interrupt نیز گفته می‌شود.

تولید سیگنال و ارسال آن به یک پروسه می‌تواند از دل کرنل رخ داده، توسط یک پروسه‌ی دیگر بوده، از طریق Terminal و به کمک دستور kill بوده و یا حتی با فشردن کلید‌هایی مثل CTRL+Z یا CTRL+C توسط کاربر انجام شود.

پروسه با دریافت Signal در صورت وجود داشتن یک Handler درون کد برنامه‌ی خود، به سراغ اجرای آن رفته و در غیر این صورت رفتار پیش‌فرضی که سیستم‌عامل برای هر سیگنال تعریف کرده است را اجرا می‌کند که در اکثر مواقع باعث Terminate شدن اجرای پروسه می‌شود. همچنین ذکر این نکته ضروری است که امکان تعریف کردن Handler برای دو سیگنال‌ SIGKILL و SIGSTOP وجود نداشته و برای این دو همیشه رفتار تعریف شده توسط سیستم‌عامل اجرا می‌شود.

برخی از سیگنال‌ها باعث تغییر در وضعیت اجرای پروسه می‌شوند. به عنوان مثال زدن CTRL+Z در اکثر برنامه‌ها باعث می‌شود که برنامه در وضعیت Stopped قرار گرفته و به Background رود و یا زدن CTRL+C به پروسه یک Interrupt داده که ممکن است اجرای آنرا متوقف کند.

در پایان این نکته را اضافه کنم که ارسال SIGKILL با شماره ۹ برای برخی از برنامه‌ها ممکن است باعث از بین رفتن داده شود. به عنوان مثال فرض کنید که یک برنامه فایلی را باز کرده و در حال نوشتن در آن است. اگر منتظر اتمام کار برنامه نمانده و وسط کار آن SIGKILL‌ ارسال کنیم بلافاصله برنامه بسته شده و نوشتن در فایل تمام نشده و بخشی از داده از بین می‌رود ولی ارسال SIGTERM با شماره ۱۵ به برنامه در صورت Handle شدن آن توسط برنامه، این فرصت را به برنامه می‌دهد که نوشتن در فایل را به اتمام رسانده و سپس بسته شود.

در این ویدئو شیوه‌ی کار سیگنال، تاثیر آن بر وضعیت پروسه و چرخه‌ی اجرای پروسه‌ها در لینوکس شرح داده شده و شیوه‌ی تعریف Handler‌ برای پردازش سیگنال در کد C‌ نمایش داده می‌شود.

لینک ویدئو در یوتیوب:
https://youtu.be/6FbpnYDeWw0
لینک ویدئو در آپارات:
https://aparat.com/v/nruhez3

#ShortLinuxInternals #linux #internals #kernel #programming #signals #processes

نمایش شیوه‌ی ایجاد پروسه‌های اولیه‌ی لینوکس و طرز کار آن‌ها از روی کد کرنل

پروسه‌ها در لینوکس یک ساختار درختی دارند و همه چیز از پروسه‌ با PID‌ یک شروع میشه که در توزیع‌های جدید لینوکس systemd است ولی در نسخه‌های قدیمی‌تر init, upstart و چیزهای دیگری می‌توانست باشد. البته یک مورد جدید و جذاب دیگه unikernel می‌باشد که در آن برنامه‌های مختلف می‌توانند به عنوان PID 1 اجرا شده و در ایجاد containerهایی با وابستگی کم کاربرد دارد.

ایجاد این پروسه در تابع start_kernel از کد کرنل که در فایل init/main.c تعریف شده است انجام می‌شود. پروسه با PID 1‌ در لینوکس یک پروسه‌ی کامل می‌باشد که هم user space داشته و هم kernel space و پروسه‌هایی که این دو را داشته باشند در ساختار درختی زیر مجموعه‌ی این پروسه می‌باشند.

پروسه‌ی دومی که در تابع start_kernel ایجاد می‌شود دارای PID 2 می‌باشد و در ساختار درختی موازی این پروسه بوده و زیر مجموعه‌ی آن نمی‌باشد. اسم این پروسه kthreadd می‌باشد و بر خلاف پروسه‌ی PID 1 دارای user space نبوده و فقط kernel space دارد. این پروسه وظیفه‌ی مدیریت kernel threadها را در لینوکس دارد که برای مدیریت کارهای مختلف سیستمی و انجام وظایف مختلف مربوط به کرنل و درایورها استفاده می‌شوند.

با شروع به کار این دو پروسه سیستم‌عامل به صورت کامل بالا آمده و مابقی پروسه‌ها می‌توانند تحت آن‌ها شروع به کار کرده و سرویس‌دهی را انجام دهند. البته یک پروسه‌ی دیگر نیز با PID 0 در لینوکس وجود دارد که در خروجی ps نمی‌توانید آنرا مشاهده کنید ولی با استفاده از ابزارهایی مثل ftrace, ebpf امکان کسب اطلاعات از آن وجود دارد.

برای اطلاع از جزئیات بیشتری که در مورد این سه پروسه‌ وجود دارد ویدئو را مشاهده کنید.

لینک ویدئو در یوتیوب:
https://youtu.be/vRwfnFXex3E
لینک ویدئو در آپارات:
https://aparat.com/v/xkl8808

#ShortLinuxInternals #linux #internals #programming #processes #kernel #systemd #initd #kernelthreads

مقدمه‌ای بر eBPF و کاربردهای آن

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

برای کسب اطلاعات از اتفاقات مختلفی که در سیستم‌عامل رخ می‌دهند و اعمال تغییرات در بخش‌های مختلف آن ابزارهای مختلفی توسعه داده شده‌اند که امکان کسب اطلاعات و یا اعمال تغییرات در نقاط مشخصی از کرنل را فراهم می‌کنند. قبلا در پستی یکی از این ابزارها به اسم ftrace را معرفی کرده‌ام و در این پست و ویدئو قصد معرفی ابزار دیگری به اسم eBPF را دارم که قابلیت‌هایی بسیار زیادی فراهم کرده و انعطاف پذیری بالایی در کسب اطلاعات و اعمال تغییرات در کرنل لینوکس را دارد.

در واقع می‌توان گفت که eBPF یک زبان تعامل با کرنل لینوکس است که به کمک آن می‌توان اطلاعاتی از کارکرد کرنل بدست آورده و یا در آن تغییراتی اعمال نمود. کد نوشته شده برای eBPF‌ پس از کامپایل به یک bytecode برای کرنل ارسال شده و اگر مشکلی نداشته باشد در کرنل اجرا می‌شود.

برای نمونه‌ای از کاربردهای eBPF‌ می‌توان به استفاده‌ی اندروید برای کسب اطلاعات از میزان استفاده از شبکه، استفاده‌ی Netflix ‌برای کسب اطلاعات آماری از شبکه در مقیاس بزرگ، استفاده‌ی گوگل برای پردازش بسته‌های شبکه و performance monitoring و یا استفاده‌ی Cloudflare‌ برای امنیت شبکه اشاره کرد.

در این ویدئو ابتدا eBPF‌ معرفی شده و سپس به کمک bpftrace استفاده از آن تست می‌شود.

لینک ویدئو در یوتیوب:
https://youtu.be/qOqi8RPf4N0
لینک ویدئو در آپارات:
https://aparat.com/v/rxzar9f

#ShortLinuxInternals #linux #internals #programming #kernel #bpf #ebpf #tracing #bpftrace

مروری بر پروسه‌های کرنلی لینوکس

در لینوکس برخی از پروسه‌ها بخش user space‌ نداشته و کامل در دل کرنل اجرا می‌شوند. این پروسه‌ها در اجرای کارهای مختلف به سیستم‌عامل کمک کرده و به صورت background کارهایی که نیاز است انجام شوند که لینوکس بتواند سرویس‌دهی موارد مختلف را انجام دهد مدیریت می‌کنند. در این پست و ویدئو برخی از این پروسه‌ها معرفی شده و کاربردهای مختلف آن‌ها شرح داده می‌شود.

اولین پروسه (نخ) کرنلی لینوکس kthreadd است که وظیفه‌ی ایجاد یک interface برای ایجاد و مدیریت پروسه‌های کرنلی در لینوکس را داشته و همیشه با PID‌ برابر ۲ اجرا می‌شود. در کد این نخ یک حلقه‌ی بی‌نهایت وجود دارد که از لیستی به اسم kthread_create_list اطلاعات پروسه‌ی کرنلی که قرار است ایجاد شود را برداشته و آنرا ایجاد می‌کند. تمامی پروسه‌های کرنلی لینوکس از اینجا به بعد فرزندان kthreadd خواهند بود.

پروسه‌ی بعدی که معرفی می‌کنیم migration است. از پروسه‌ی کرنلی migration به تعداد coreهای cpu خواهیم داشت و وظیفه‌ی آن مدیریت پروسه‌هایی است که بر روی یک core اجرا می‌شوند و در صورت زیاد بودن بار بر روی یک core یک پروسه را از روی run_queue یک core بر داشته و بر روی run_queue یک core دیگر قرار می‌دهد.

پروسه‌ی دیگری که در ویدئو در مورد آن صحبت شده است kcompactd است که وظیفه‌ی آن جلوگیری از ایجاد fragmentation‌ در حافظه و کمک به کنارهم قرار گرفتن pageهای مرتبط در حافظه است.

یک پروسه‌ی جالب دیگر oom_reaper است که در صورتیکه سیستم‌عامل با کمبود حافظه مواجه شود دست به کار شده و با kill کردن یک پروسه فضای لازم را برای کار مابقی پروسه‌ها فراهم می‌کند.

در ویدئو در مورد پروسه‌های بیشتری صحبت شده است که می‌توانید با مشاهده‌ی آن از این پروسه‌ها اطلاع پیدا کنید.

لینک ویدئو در یوتیوب:
https://youtu.be/PsZ5GZhzvqE
لینک ویدئو در آپارات:
https://aparat.com/v/obt29c7

پ.ن ۱:‌ برای اطلاع از جزئیات پروسه‌های ابتدایی لینوکس پست زیر را مشاهده کنید:
https://t.me/OxAA55/133

پ.ن ۲: برای اطلاع از جزئیات پروسه و نخ در لینوکس پست زیر را مشاهده کنید:
https://t.me/OxAA55/124

#ShortLinuxInternals #linux #internals #programming #kernel #memory #threads #processes #kernel_threads