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

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

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

شروع فصل دوم دوره Windows Internals در مورد Debugging
از امروز به صورت هفتگی هر ۴شنبه [[بسته به مشغله کاری ممکنه البته بشه یک چهارشنبه در میان]] در مورد Debugging ویدئوی جدید خواهیم داشت. ویدئوها همزمان بر روی آپارات و یوتیوب منتشر می‌شوند که در ادامه لینک‌ها رو می‌تونید ببینید.

لطفا منتشر کنید که دوستان علاقه‌مند استفاده کنند. اینم لینک کانال تلگرام، عضو بشید که کلیه‌ی مواردی که قبلا منتشر شده و مقاله‌هایی که در آینده قصد انتشار دارم رو داشته باشید:
https://t.me/OxAA55

اما این هفته ۲ ویدئو داریم که معرفی مطالب فصل و روند Compile رو در بر دارند.
1. این اولین ویدئوی فصل دوم دوره‌ی Windows Internals است که در آن به موضوع دیباگ می‌پردازیم. در این ویدئو دلیل افزودن این فصل به دوره و مباحثی که در این فصل پوشش می‌دهیم معرفی می‌شوند.
https://aparat.com/v/0Xm2d
https://youtu.be/pSekiGgplRc

2. در این ویدئو ابتدا با مراحلی که یک فایل source طی کرده تا به فایل باینری تبدیل شود آشنا شده و سپس به ساختار برنامه‌ها بر روی دیسک، و در حالت اجرایی در حافظه می‌پردازیم. تبدیل شدن فایل cpp به فایل پیش‌پردازش و تغییر macroها، تبدیل شدن به اسمبلی و در نهایت linkشدن object fileها و تولید فایل PE نمایش داده شده و مرور کوتاهی بر روی ساختار PE به کمک PEBear انجام می‌دهیم. در نهایت نیز ساختارهای heap, stack و قرار گیری اطلاعات در آن‌ها به کمک Visual Studio نمایش داده می‌شود.
https://aparat.com/v/ST2Ia
https://youtu.be/pXRZaK6ZjqM

#windows #internals #debug #compile #stack #heap #pe #pebear #visualstudio #programming #cpp

تجربه‌ی تولید محتوا در مورد 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

دوستان سلام
تصمیم گرفتم در کنار روند آموزشی Internals Sessions که داریم بخش‌هایی از کلاس‌هایم رو هم در قالب ویدئوهای کوتاه منتشر کنم و یکسری از مفاهیم سیستم‌عامل رو شرح دهم.

در اولین قدم با ذکر یک مثال ساده، به بررسی تاثیر متغیرهای TLS (Thread Local Storage) در برنامه‌های چند نخی می‌پردازیم.

فضای حافظه‌ای که پروسه‌ها دارند، بین threadهای مختلفی که در پروسه ایجاد می‌شوند مشترک بوده و همگی به آن دسترسی دارند و علت اینکه در برنامه نویسی چندنخی باید به Synchronization بین نخ‌ها توجه کنیم همین موضوع است. ولی برخی مواقع داشتن فضایی که به ازای هر نخ منحصر به فرد باشد لازم است. مثلا زمانیکه یک تابع با خطا مواجه شده و نیاز به ارسال کد خطا دارد یا زمانیکه استثنایی در فراخوانی یک تابع رخ می‌دهد. در این مواقع باید فضای استفاده شده برای کد خطا Per Thread باشد و استفاده شدن آن به صورت مشترک باعث بروز رفتار غیرقابل پیش‌بینی می‌شود.

به عنوان مثال در برنامه‌نویسی C متغیر errno در فضای TLS نگه‌داری می‌شود که خطای رخ داده در threadهای مختلف فقط در همان thread بوده و مشکلی ایجاد نشود. در API ویندوز هم تابعی به اسم GetLastError وجود دارد که کار مشابهی می‌کند ولی این تابع مقدار یک متغیر موجود در TEB (Thread Environment Block) را باز می‌گرداند که در فضای TLS‌ نیست ولی آن هم Per Thread بوده و مفهوم مشابهی دارد.

در این ویدئو به بررسی شیوه‌ی تعریف متغیرهای TLS در ویندوز و تست آن می‌پردازیم.
لینک ویدئو در یوتیوب:
https://youtu.be/1SHLyoicm-s
لینک ویدئو در آپارات:
https://aparat.com/v/YTCgV


#ShortWinInternals #windows #internals #cpp #programming #threads #TLS

نمایش دمو از مفهوم Thread Context

مفهوم Thread Context در ویندوز به داده‌های ضروری اشاره دارد که وضعیت کنونی Thread را در زمان اجرا در پروسه تعریف می‌کند. این اطلاعات شامل مقادیر Registerها مثل RIP برای نگهداری آدرس بعدی که باید کد از آن اجرا شود، اشاره‌گرهای Stack و مقادیر Flagها برای مشخص کردن نتیجه‌ی اجرای دستور قبلی و وضعیت CPU‌ هستند.

زمانیکه CPU از یک Thread ‌گرفته شده و Thread دیگری برای اجرا انتخاب می‌شود، این اطلاعات توسط سیستم‌عامل ذخیره می‌شوند که پس از اینکه CPU مجدد در اختیار Thread جاری قرار گرفت، اجرا بدون مشکل بتواند ادامه پیدا کند. این عملیات همان چیزی است که در مباحث سیستم‌عامل به آن با عنوان Context Switching اشاره می‌شود. (دقت کنید که در ویندوز پروسه اجرا نشده و فقط یک Container برای فراهم کردن یک فضای مشترک و دسترسی به یکسری منابع است. آن چیزی که در ویندوز اجرا می‌شود Threadها هستند.)

در این ویدئو که بخشی از یکی ازکلاس‌هایم است، ابتدا به کمک برنامه نویسی به Thread Context دسترسی پیدا کرده و به کمک ابزارهای ProcessExplorer و WinDbg جزئیات و شیوه‌ی کار Thread را بررسی می‌کنیم. سپس تاثیر تغییر دادن Context‌ و جایگزین کردن RIP و تغییر مسیر اجرای Thread را بررسی می‌کنیم که با یکی از روش‌های Injection کد در Thread آشنا شویم.

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

#ShortWinInternals #windows #internals #cpp #programming #thread #context

بررسی قرارداد فراخوانی توابع در برنامه‌های ۳۲بیتی

در این ویدئو که بخشی از یکی از کلاس‌هایم است، در مورد قراردادهای مختلف فراخوانی توابع در برنامه‌های ۳۲بیتی صحبت کرده و در یک برنامه‌ی ساده شیوه‌ی انجام آن‌ها را نمایش می‌دهم.
این فراخوانی‌ها عبارتند از: STDCALL، CDECL و FASTCALL

مدل STDCALL از stack برای انتقال پارامترهای تابع استفاده کرده و در آن تابعی که فراخوانی شده است(Callee) پس از اتمام، پارامترها را از روی stack حذف می‌کند. این مدل در اکثر توابع WinAPI‌ مورد استفاده قرار می‌گیرد.

مدل CDECL مشابه STDCALL‌ است ولی در آن تابعی که فراخوانی را انجام می‌دهد(Caller) پاک‌سازی stack را بر عهده دارد. این مدل در توابع C/C++ پیش‌فرض بوده و در لینوکس نیز از آن استفاده می‌شود.

مدل FASTCALL همانطور که از نامش پیداست، با استفاده از رجیسترها برای انتقال آرگومان‌های تابع «البته فقط دو پارامتر اول با رجیستر ارسال شده و مابقی از طریق stack‌ارسال می‌شوند» سعی در سرعت بخشیدن به اجرا دارد. پاکسازی stack در صورت نیاز، مشابه STDCALL توسط تابع فراخوانی شده(Callee) انجام می‌شود.

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

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

#ShortWinInternals #windows #internals #CallingConventions #x86 #stdcall #cdecl #fastcall #programming #cpp

محدود کردن اجرای پروسه‌ها به کمک 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

مروری بر روش‌های IPC در لینوکس و تست SharedMemory

بحث IPC یا Inter-Process Communication به روش‌هایی گفته می‌شود که از طریق آن دو پروسه می‌توانند با یکدیگر اطلاعاتی رد و بدل کرده یا یک رخ‌داد را به اطلاع هم برسانند. برای انجام اینکار متدهای متنوعی در لینوکس وجود دارد که قبلا نیز در مورد Signal پستی منتشر کرده بودم و جزئیات آنرا نمایش داده بودم.

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

برای استفاده از حافظه‌ی مشترک در لینوکس، با استفاده از shm_open درخواست ایجاد فضای مشترک را داده و پس از دریافت یک File Descriptor به کمک mmap حافظه‌ی مورد نیاز را از کرنل لینوکس دریافت می‌کنیم.

نکته‌ای که باید به آن توجه کنیم این است که نوشتن چند پروسه به صورت همزمان درفضای مشترک، می‌تواند ناسازگاری داده ایجاد کند که با استفاده از Semaphore یا روش‌های دیگر Synchronization بر اساس نیاز، باید بین پروسه‌ها هماهنگی ایجاد نمود.

در این ویدئو، پس از مرور کوتاهی بر روش‌های مختلف IPC به بررسی عمیق‌تر روش Shared Memory پرداخته و یک کد ساده برای تست آن می‌زنیم.


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

#ShortLinuxInternals #linux #internals #programming #processes #ipc #sharedmemory

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

قبل از توضیح این بخش لازمه مجدد اشاره کنم که thread/process در کرنل لینوکس با task_struct‌ پیاده‌سازی شده‌اند و در این پست بجای تکرار «اجرای پروسه و نخ» در لینوکس از عبارت اجرای وظیفه یا task استفاده می‌کنیم. با این مقدمه برسیم به اصل موضوع این پست:

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

لینوکس برای مشخص کردن اولویت اجرای taskها بر روی پردازنده و مدت زمانی که می‌توانند از پردازنده استفاده کنند الگوریتم‌های مختلفی دارد که به آن‌ها class یا policy زمان‌بندی می‌گوید. در هر کلاس نیز به کمک یک عدد، اولویت اجرای taskها را مشخص می‌کند. به عنوان مثال زمان‌بند پیش‌فرض لینوکس که در کلاس Normal قرار دارد با عنوان Completely Fair Scheduler شناخته می‌شود که در پیاده‌سازی آن از Red-Black Tree که یک درخت جستجوی دودویی Balance می‌باشد کمک گرفته شده است.

یک کلاس دیگری که در لینوکس وجود دارد کلاس RealTime می‌باشد. البته منظور از RealTime در این مورد این است که وظایف تحت یک Time Frame مشخص اجرا می‌شوند. در این کلاس امکان استفاده از روش‌های Round-Robin یا FIFO وجود دارد.

تنظیم کردن اولویت وظایف در کلاس نرمال توسط مقدار nice مشخص می‌شود که عددی در بازه‌ی منفی ۲۰ تا مثبت ۱۹ می‌باشد. در کرنل لینوکس مقدار نهایی اولویت برای الگوریتم‌های مختلف می‌تواند عددی بین صفر تا ۱۳۹ باشد و موارد مختلفی مثل Boost کردن اولویت برای پاسخ‌دهی سریع‌تر برنامه‌های گرافیکی یا وظایفی که وابستگی خاصی به آن‌ها وجود دارد نیز در اولویت نهایی تاثیر دارند. برای داشتن مقدار تنظیم شده برای اولویت و مقداری که کرنل تصمیم می‌گیرد اولویت وظیفه در زمان جاری باشد فیلد‌های متفاوتی در task_struct وجود دارند.

به عنوان نکته‌ی پایانی باید اشاره کنم که تنظیم کردن اولویت وظایف به کمک syscall ای به اسم setpriority انجام می‌شود که دستور renice نیز از آن استفاده می‌کند. به کمک دستور chrt نیز می‌توان تنظیمات مربوط به کلاس RealTime را تغییر داد.

شرح کامل موارد ذکر شده، نمایش دمو از شیوه‌ی استفاده از آن‌ها و نمایش کد کرنل مربوط به setpriotity مواردی هستند که در این ویدئو به آن‌ها می‌پردازیم. برای مشاهده‌ی ویدئو از لینک‌های زیر استفاده کنید:

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

پ.ن: اگر شیوه‌ی پیاده‌سازی پروسه/نخ در لینوکس و کاربرد task_struct برای شما شفاف نیست به پست زیر مراجعه کنید:
https://t.me/OxAA55/124

#ShortLinuxInternals #linux #internals #programming #processes #sheduling #tasks #task_struct #nice #priority

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

پروسه‌ها در لینوکس یک ساختار درختی دارند و همه چیز از پروسه‌ با 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

📢 انتشار فصل اول دوره توسعه اکسپلویت در لینوکس

📚 این فصل شامل ۷ ویدئو می‌باشد و در آن با مفاهیم بنیادین اجرای برنامه‌ها در سیستم‌عامل لینوکس آشنا می‌شوید؛ از مروری بر برنامه‌نویسی و ساختار فایل‌های اجرایی گرفته تا نحوه‌ی ایجاد و اجرای پروسه‌ها و مدیریت حافظه. این فصل پایه‌ای محکم برای درک مباحث پیشرفته‌تری ایجاد می‌کند که در فصل‌های آینده به آن‌ها خواهیم پرداخت.

✍️ لینک ویدئوهای فصل در یوتیوب:
00) Course Introduction
P01-01) Programming Review
P01-02) ELF Intro
P01-03) Process Execution
P01-04) Heap Investigation
P01-05) Process Address Space
P01-06) Virtual Memory
P01-07) Syscalls Intro

✍️ لینک ویدئوهای فصل در آپارات:
https://aparat.com/v/qxvin87
https://aparat.com/v/fwd0751
https://aparat.com/v/ljqz0v8
https://aparat.com/v/pdw1xkk
https://aparat.com/v/nct8m83
https://aparat.com/v/eak4pvp
https://aparat.com/v/lbuc0q0
https://aparat.com/v/sfb8398

#linux #exploitdev #internals #programming #security