اترنت و auto negotation

خب فرض کنید که سیستمون رو به یه سوئیچ وصل می‌کنین.
می‌بینین که بدون هیچ کار اضافه‌ای، سوئیچ و سیستمتون اترنت هم رو می‌شناسن و با هم ارتباط می‌گیرن ولی خب اگه مثلا به پورت سریال کار کرده باشین می‌دونین که برای هر پروتکلی تنظیمات زیادی وجود داره مثلا توی سریال baud rate داریم، parity bit داریم، طول خود پکتای سریالمون هست و...

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

جواب auto negotiation عه. پروتکلی که تو لایه فیزیکی(قبل Ethernet یا بخش فیزیکی اترنت هم میگن بهش) قرار داره و به کمک اون لینک‌ها از اطلاعات هم دیگه مطلع میشن و تصمیم می‌گیرن چجوری با هم کار کنن.

مثلا اترنت اون اوایل که فقط یه لینک فیزیکی وجود داشت و همه سیستم‌ها به اون لینک متصل میشدن، half duplex بوده و دوتا سیستم همزمان نمیتونستن رو لینک فیزیکی دیتا بفرستن و بگیرن اما امروزه که سوئیچ‌ها رو داریم و کابل‌کشی عوض شده تقریبا همه‌جا ارتباط full duplex داریم.
این یکی از مواردیه که توی auto negotiation بین stationها منتقل میشه و تصمیم‌گیری میشه که کدوم یکی استفاده شه.

یا مثلا سرعت لینک
فرض کنین یه nic تا 2.5GB سرعت می‌تونه داشته باشه ولی یکی تا 100MB. خب اینجا طرفین به هم اطلاع میدن و سرعت لینک پایین‌تر انتخاب میشه

میشه با ethtool توی لینوکس دید که پورتای اترنتتون چه تنظیماتی دارن و این مورد براشون فعال هست یا نیست و میشه این مورد رو غیرفعال هم کرد ولی غیرفعال کردنش اصلا توصیه نمیشه. دلیلش هم اینه که اگه یه طرف کارت شبکه قدیمی داشته باشیم که فقط half duplex بتونه کار کنه و یه طرف دیگه full duplex باشه، بشدت افت سرعت خواهیم داشت.
پس توصیه میشه که این گزینه رو همیشه روشن نگه دارین مگر در شرایطی که خب مطمئنین باید خاموش باشه

اترنت و STP

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

این قضیه مشکل سازه چون اینکه چه سیستمی(چه مک آدرسی) به چه پورتی از یه سوئیچ وصله توی سوئیچ ذخیره میشه(forwarding table میگن بهش) و خب وقتی بیش‌تر از یک مسیر باشه، سوئیچ ممکنه گیج بشه و مدام این جدولش عوض شه که خوب نیست. یا برای فرستادن broadcast frame ها، اگه حلقه داشته باشیم، فریممون میوفته تو حلقه و خب اینجوری تا ابد بین سوئیچ‌ها می‌چرخه که اصلا خوب نیست.

راه حل چیه؟
اینه که گراف شبکمون، بدون دور باشه و برای وصل کردن هر دوتا نود، فقط یه مسیر داشته باشیم.
پروتکل STP کارش همینه و درواقع با غیرفعال کردن یه سری پورت‌های سوئیچ، این قضیه رو خودبخود رفعش می‌کنه.
البته STP سال 1990 اومد و خب یه‌سری مشکلات داشت و به همین دلیل جایگزینش که RSTP باشه، سال 2001 اومده.

پروتکل‌های STP و RSTP با فریم‌هایی به اسم BPDU یا bridge protocl data unit برای ارتباط بین سوئیچ‌ها استفاده می‌کنن.

بذارید یکم ریزتر و دقیق‌تر STP رو بررسی کنیم. این پروتکل اینجوری کار می‌کنه که برای پورت‌های سوئیچ یه state machine تعریف می‌کنه و خب قاعدتا یه سری state.
مثلا میگه وقتی سوئیچ روشن شد، همه پورتا میرن روی حالت blocking البته بجز پورتایی که دستی و توسط ادمین غیرفعال تعریف شدن.
توی حالت بلاکینگ پورت فقط می‌تونه BPDU ها رو ببینه و اگه دید طبق BPDUی ورودی قراره توی یه مسیری باشه، از blocking میره به مد listening. توی این مد، پورت می‌تونه علاوه بر شنیدن bpduها، اونا رو ارسال هم بکنه ولی هیچ کار دیگه‌ای نمی‌تونه انجام بده.
نهایتا پورتی که توی listening مد هست، بعد یه مدت زمان مشخصی(۱۵ ثانیه) میره به حالت learning و توی این حالت پورت تنها کاری که نمی‌تونه بکنه، ارسال و دریافت فریم‌های دیتاست(می‌تونه bpdu بفرسته و بگیره و میتونه forwarding table رو پر کنه ولی نمی‌تونه فریم‌های دیتایی که بین stationها جابجا میشن رو بفرسته یا بگیره).
بعد از این مد هم، با یه تاخیر بیست ثانیه پورت میره توی حالت forwarding که دیگه میتونه هرکاری انجام بده.

مشکلی که STP داره همینه که تاخیر زیادی داریم و حداقل چهل پنجاه ثانیه تاخیر لازمه تا یه پورت بره توی حالت عادی. RSTP که مخفف rapid stpعه دقیقا این مشکل رو حل می‌کنه و تاخیر پورت‌ها رو نهایتا به یکی دوثانیه میرسونه که خب خیلی خوبه

A guide to SDR and DSP using Python
https://pysdr.org/content/intro.html

#sdr

خیلی آموزش خوبیه
مثلا موارد زیر جزو چیزایی که یاد میده
Sampling basics
IQ Sampling
FFT
Complex numbers
Signal Power and Power Spectral Density
Digital Modulations (ASK, PSK, FSK, QAM)
AWGN, SNR, SINR, Noise, Gaussian Noise
Filtering, FIR, IIR
Pulse Shaping
Channel Coding
Beamforming and DOA
...

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

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

✍️ لینک ویدئوهای فصل در یوتیوب:
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

glibc
این کلمهٔ پنج حرفی خیلی حرف برای گفتن داره
خیلیییی

ببینید ما میایم یه کد سی توی لینوکس می‌نویسیم. مثلا کد hello world با استفاده از تابع printf
این برنامه رو که کامپایل می‌کنیم، اگه ldd بگیریم ازش خواهیم دید که به glibc لینک شده. برنامه‌ای که چهار خطه مجموعا، دیپندسی glibc داره و خب این خودش نشون‌دهندهٔ اهمیت glibcعه.

اما ایشون چیکار میکنه؟
خیلی کارها که یه سریاشو هنوز مطمئنم نمی‌دونم. ولی اگه بخواید glibc رو حذف کنید، خیلی همه چی سخت خواهد شد. مثلا شما تنها راه ارتباط با کرنلتون صدا زدن مستقیم سیستم‌کال‌ها با شمارشون خواهد بود.
یعنی اگه بخواین حتی یه متن چاپ کنین، باید سیستم‌کال write رو صدا بزنین اونم نه با تابع write چون خود این تابع عضوی از glibcعه بلکه با کد اسمبلی!

پس اهمیت ایشون خیلی زیاده
یکی دیگه از کارایی که انجام میده، اینه که تابع main برنامه ها رو ایشون صدا می‌زنه!
درواقع اگه شما توی یه برنامه ای از glibc استفاده نکنین، لزومی نخواهد داشت که تابع main داشته باشین (استفاده هم بکنین لزومی نداره البته) چون این تابع رو کرنل موقع اجرای برنامه صدا نمیزنه بلکه glibc runtime صداش میزنه.

کرنل فقط یه فایل ELF می‌بینه که یه entry point داره و برنامه رو از اون نقطه اجرا می‌کنه. هیچ اصراری هم بر اسم main نداره.

یکی دیگه از کارای وحشتناک حیاتی جناب glibc، لودر پویا یا dynamic loader ایشونه. کرنل لینوکس اصلا dynamic loading نداره😂
پس اگه برناممون دیپندنسی کتابخانه‌ای به چندتا shared library داره، توی ELF فایل مشخص می‌کنه و به کرنل میگه بجای اینکه entry point من رو اجرا کنی، برو فلان interpreter رو اجرا کن که برای برنامه های glibc دار، این اینترپتره میشه ld-linux.so که بخشی از glibc عه و نه کرنل.

پس glibc خیلی نقش حیاتی‌ای داره.

جالبه بدونید که چندتا جایگزین هم داره مثلا musl که یه ورژن سبک‌تر از glibcعه

یا bionic که مال گوگل و اندرویده و کاملا اپن سورسه یا crt و ucrt ویندوز

یه نکته دیگه اینکه اگه بتونین توی libcها باگ پیدا کنین، خیلی باگ خفنی حساب میشه

همزمانی در سی‌پلاس‌پلاس
پست ۶

توی این پست میخوام درمورد deadlock بیش‌تر صحبت کنم.
اصولا deadlock موقعی پیش میاد که به هر دلیل دوتا ترد به شکل دایره وار منتظر همدیگه بمونن. یکی از دلایل این انتظار میتونه میوتکس(میوتک؟)ها و یا درواقع ریسورس‌ها باشن ولی دلایل دیگه مثل طراحی بد هم میتونه باعث انتظار و deadlock بشه.

راه حل چیه؟
اولین و شاید بشه گفت مهم ترین نکته برای رفع deadlock اینه که قاعده زیر رو رعایت کنیم:
همیشه n تا میوتکس رو به یک ترتیب لاک کنید.

اگه این قاعده رعایت شه، از نظر ریسورسی یا همون میوتکسی به مشکلی نمی‌خوریم هرچند که ممکنه طراحیمون هنوز مشکل داشته باشه. دلیل اینکه چرا این روش کار میکنه رو میتونین با کشیدن چیزی به اسم گراف wait-for ببینین.

نکته دومی که میتونه کمک کننده باشه اینه که تا جایی که ممکنه از nested lockها بپرهیزید. این نکته هم میتونه جلوی طراحی‌های مشکل دار رو بگیره.


اما C++ چی در چنته داره؟
خب حداقل دوتا عنصر خوب داریم، کلاس std::scoped_lock که از c++17 پیداش میشه و یک تابع که شاید بشه گفت ورژن قدیمی‌تر این کلاسه، std::lock

اول با std::lock شروع کنیم. کانسپت ساده‌ای داره. این تابع n تا میوتکس رو می‌گیره و به ما قول میده جوری لاکشون کنه که deadlock رخ نده (واقعا نمیدونم چجوری).

و اما std::scoped_lock یه template کلاسه که توی متد سازندش n تا میوتکس رو می‌گیره و جوری لاکشون میکنه که deadlock رخ نده و البته توی دیستراکتورش همه میوتکس‌هایی که بهش داده شده بود رو مثل std::lock_gaurd آنلاک می‌کنه.

به این دلیل این کلاس template classعه که چندین نوع mutex داریم و کلاس انتظار داره تایپ میوتکس‌های ورودی بهش رو بهش بگیم. البته که چون این کلاس توی c++17 اضافه شده و همزمان توی همین ورژن template deduction به استاندارد اضافه شده، میتونین template argument ها رو بهش پاس ندین و بذارین خودش تشخیصشون بده.


توجه کنید که ممکنه لاک کردن میوتکس‌ها با خطا یا exception مواجه بشه که در اینصورت هردوتا عنصر بالا همه میوتکس‌های دیگه‌ای که لاک کردن رو آنلاک می‌کنن و اکسپشن بوجود اومده رو rethrow میکنن.

توی پست بعدی درمورد std::promise و std::future صحبت می‌کنیم.

ادامه

#cpp
#concurrency
#programming

بردیا توی کانالش یه آموزش Qt/QML فارسی خیلی خوب گذاشته:

https://youtube.com/playlist?list=PLuU5PicIfhjhVeRfN-wum_LFUPq3J0w-e

#cpp
#qt
#programming

همزمانی در سی‌پلاس‌پلاس
پست ۷
promise and future

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

داستان از اینجا شروع میشه که قراره چندین thread با هم تعامل داشته باشن. مثلا شما یه برنامه دارید که یه فایل رو از اینترنت دانلود میکنه و این دانلود برنامه این شکلیه که ده تا thread همزمان فایل رو ده تیکه میکنن و دانلودش میکنن و نهایتا وقتی کار تک تکشون تموم شد، ما باید به نحوی بفهمیم و تیکه‌های فایل‌ها رو کنار هم بچینیم تا برسیم به فایل اصلی.

سوال اینه
چجوری بفهمیم چندتا ترد کارشون تموم شده؟

یا کلی‌تر بگیم
چه راه‌های ارتباطی‌ای بین تردها وجود داره؟

خب
چندتا مکانیزم هستن که به ما کمک میکنن بین تردها دیتا جابجا کنیم. یا اصلا یه ترد به ترد دیگه بگه من کارم تموم شد و...

یکی از معروف‌ترین‌هاش همین future و promise ها هستن.

برای اینکه بهتر بفهمیم اینا چین، مثال زیر رو ببینین:
فرض کنید قراره برای شما یه ایمیل بیاد که براتون خیلی مهمه و میخواین به محض رسیدن ایمیل اون رو ببینین.

دوتا راه پیش رو خواهید داشت. یکی اینکه هر مثلا بیست ثانیه ایمیلتون رو چک کنید ببینین ایمیل جدید اومده یا نه.
یکی دیگه اینکه نوتیف ایمیلتون رو فعال کنید تا وقتی ایمیل رسید، بفهمین.

واضحه که راه دوم بهتره و برای ترد‌ها هم همین داستان رو داریم.
میخوایم وقتی یه ترد منتظر دیتایی از سمت ترد دیگست، به حالت sleep بره نه اینکه توی یه حلقهٔ بینهایت دور بزنه و مدام چک کنه آیا دیتا رسید یا نه.
اینجا دقیقا promise و future ها بکار میان.
البته condition_variable ها هم با تقریب خوبی همین کاربرد رو دارن که بعدتر توضیح میدم.

پس هروقت لازم داشتیم یه ترد از یه ترد دیگه یه دیتایی رو بگیره، یا صرفا بفهمه که اون ترد کارش تموم شد از promise و future استفاده میکنیم.

طریقه استفادش اینطوریه که
۱) یه std::promise می‌سازیم. این کلاس یه template class عه که تایپی که می‌گیره تایپ دیتایی که قراره بعدا توی یه ترد دیگه ازش بگیریم. (اگه قرار نیست دیتایی بگیریم و صرفا قراره بفهمیم کار ترد تموم شده تایپ void بهش میدیم)
۲) آبجکت future رو از promise ساخته شده با تابع get_future استخراج می‌کنیم.
۳) تابع future.wait یا future.get رو صدا می‌زنیم. تابع wait برای حالتیه که دیتایی قرار نیست به ما برگرده و فقط قراره منتظر اتمام کار ترد باشیم و تابع get برای حالتیه که ترد واقعا دیتا بر می‌گردونه. این توابع blocking هستن. یعنی تردی که این توابع رو صدا بزنه، میره به حالت sleep تا موقعی که دیتا آماده بشه.
توابع wait_for و wait_until رو هم داریم که به این صبر کردنه تایم اوت اضافه می‌کنن.

توی لینک زیر می‌تونین مثال ببینین از این کلاس‌ها:
https://en.cppreference.com/w/cpp/thread/future.html

اینجا هم یه ارائه خوب داریم که std::promise و std::future رو پیاده‌سازی میکنه:
https://youtu.be/jfDRgnxDe7o


#cpp
#programming
#concurrency

توجه کنید که future و promise اکثرا در مواقعی استفاده میشن که تسکمون one off باشه

ینی یه تسکی داریم که یه نتیجه داره و یه بار قراره انجام شه.
اگه غیر از این باشه از condition variable ها استفاده میکنیم

خیلیا زبان برنامه نویسی اسمبلی رو معمولاً برای نوشتن کدهای کوچیک یا بهینه‌سازی توابع می‌شناسن، این شخص اومده بهتون نشون بده چطوری می‌شه چیزای گرافیکی باهاش بسازین

کار سختی نیست فقط باید حوصله کنید بخونیدش، چیزای خوبی یاد می‌گیرین :

gaultier.github.io/blog/x11_x64.html


@Linuxor

Author: zarvan
Language: Persian
Telegram channel: @web_articles

این کتاب رایگان هست و هیچ قیمتی براش نذاشتم. اما اگه دوست داشتید از من حمایت کنید، می‌تونید از این لینک استفاده کنید:

https://daramet.com/web_articles


همچنین می‌تونید با به اشتراک گذاشتن کتاب، کمک کنید که بیشتر دیده بشه.

Storage duration
و
Linkage


فرض کنید یه برنامه c یا cpp داریم که از چندین فایل تشکیل شده

سوال اینه که identifierای که به صورت گلوبال تعریف شده آیا توی همه فایلای دیگه قابل دسترسیه و عملا اون identifier دیگه نمی‌تونه استفاده بشه؟ و اینکه آیا میشه این مشکل(؟) رو رفع کرد؟

برای پاسخ به این سوالات باید با سه تا مفهوم آشنا باشیم
یکیش scope یه متغیره که فک کنم همه آشنا هستیم باهش
اون دوتای دیگه linkage متغیر و storage duration اونه

Storage duration
این خاصیت یه متغیر مشخص میکنه که متغیر کی ساخته میشه و کی ازبین میره. سه تا مدل داریم:
> Dynamic duration
برای متغیرهایی استفاده میشه که توسط برنامه‌نویس تعریف میشه کی از بین بیان و کی از بین برن. درواقع همون متغیرهایی هستن که توی heap قرار میگیرن و با new و free یا delete بوجود میان و از بین میرن

> Static storage duration
متغیرهایی با این duration، از ابتدا تا انتهای برنامه توی مموری وجود دارن

> Automatic duration
این مدل متغیرها اول یه بلوک (یه آکولاد باز و بسته) بوجود میان و آخر اون از بین میرن. مثل متغیرهایی که توی یه تابع تعریف میشن

اما مورد دوم
Linkage
این مورد مشخص می‌کنه که یه identifier در scopeهای مختلف به یک موجود اشاره می‌کنه یا نه. این مورد هم سه مدل داره:
> No linkage
توی این حالت، identifer های مختلف به چیزهای مختلفی اشاره میکنن. مثلا وقتی دوتا متغیر با یک اسم توی دوتا اسکوپ مختلف تعریف میشن، این مدل linkage رو دارن.

> Internal linkage
این مدل linkage مشخص می‌کنه که یه identifier توی یه translation unit مربوط به یک عنصر منحصر به فرده. مثلا اگه یه متغیر گلوبال و static تعریف بشه، توی کل اون فایل identiferاش به اون متغیر اشاره می‌کنه.
درواقع Identifier های
متغیرهای گلوبال و static
توابع استاتیک
متغیرهای گلوبال const
و unnamed namespace ها و عناصر تعریف شده داخلشون
این linkage رو دارن

> External linkage
و مدل آخر linkage، مدل external linkage هست. Identiferای با این مدل linkage در تمام برنامه یکتا خواهد بود و به یک عنصر اشاره خواهد داشت.
موارد زیر identifier هاشون این خاصیت رو داره:
توابع غیر static
متغیرهای گلوبال non-const
متغیرهای گلوبال extern const
متغیرهای گلوبال inline const
و named namespace ها


سورس:
https://www.learncpp.com/cpp-tutorial/scope-duration-and-linkage-summary/

#cpp
#programming

احساس میکنم کم کم باید بلاگ بزنم😂

اینجا نمیشه درست ویراستاری کرد

📢 انتشار فصل ششم دوره Linux Exploit Development

ℹ️ مقدمات برنامه‌نویسی ROP

📚 در این فصل وارد دنیای Return Oriented Programming (ROP) می‌شویم؛ تکنیکی قدرتمند برای دور زدن مکانیزم‌های امنیتی مدرن مثل NX، ASLR و PIE. با یادگیری ROP می‌توانیم بدون نیاز به اجرای مستقیم شل‌کد، با استفاده از «گجت»‌های موجود در باینری یا کتابخانه‌ها، جریان اجرای برنامه را کنترل کنیم و به اهداف دلخواه برسیم.

در این فصل ابتدا با فلسفهٔ ROP و اینکه چرا اصلاً به آن نیاز داریم آشنا می‌شویم، سپس یک مثال کلاسیک را بررسی می‌کنیم، یاد می‌گیریم چگونه با ترکیب GDB و Pwntools یک ROP chain بسازیم و در نهایت با حل چند چالش واقعی ۳۲ و ۶۴بیتی مهارت‌های ROP خود را تثبیت می‌کنیم.

✍️ لینک ویدئوهای فصل ۶ در یوتیوب:
P06-01) Why and What of Return Oriented Programming
P06-02) ROP Example from the Slides
P06-03) Using GDB with PwnTools
P06-04) Solving PicoCTF 2022 BOF2 x64 Using ROP
P06-05) Solving PicoCTF 2022 ropfu - x86 ROP

✍️ لینک ویدئوهای فصل ۶ در آپارات:
https://aparat.com/v/jvk1197
https://aparat.com/v/qrmoa1w
https://aparat.com/v/mduh9nw
https://aparat.com/v/ebe78jn
https://aparat.com/v/qne1782

#linux #exploitdev #gdb #rop #buffer_overflow #x64 #PicoCTF #CTF

Embedded linux

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

برد کاستوم شده که خب ندارم ولی با orangepi zero3 کار رو یه مقدار جلو بردم و میخوام تجربم رو به اشتراک بذارم.

اول از همه باید ببینیم چه مواردی لازمه تا اینکه یه کرنل بوت شه که خب بسته به پردازنده مدلهای بوت مختلفی داریم ولی یه بخشیش مشترکه.
اگه سیستممون intel based باشه، معمولا اولین کدی که بعد از زدن دکمه پاور اجرا میشه، کد BIOS/UEFI هست که از یه چیپ BIOS/UEFI میاد. این کد با بهش کد ROM میگن، چندان read only نیست و قابل تغییره ولی اگه بریم توی محیط غیر اینتلی و مثلا یه میکروی آرم allwinner داشته باشیم، دیگه واقعا کد ROM توی یه حافظه read only تو خود سی پی یو قرار داره و اولین کدی که اجرا میشه اونه.

این کد توی سیستم امبددمون، تقریبا تنها کاری که میکنه اینه که از یه جایی(معمولا sd card یا eMMC) یه کدی رو برمی‌داره و میریزه توی SRAM که باز یه حافظست داخل خود چیپ SoC و اون رو اجرا می‌کنه.
اینجا نکته‌ای که وجود داره اینه که SRAM فضای خیلی محدودیه پس باید حجم این کد خیلی کم باشه.

شاید بپرسین چرا اصلا توی SRAM لود میشه و چرا مستقیم نمی‌ریم توی DRAM مثل سیستم‌های اینتلی؟
جواب اینه که چیپ کنترلر DRAM باید اول initialize بشه.
کاری که توی دسکتاپ های اینتلی، همون چیپ UEFI زحمتش رو قبل از لود کردن بوت لودر میکشه ولی اینجا این چیپ وجود خارجی نداره!
البته توی سیستم های امبدد هم چیزی شبیه به اینتل داریم ولی مرسوم نیست. درواقع در فضای امبدد استاندارد مشخصی برای این قضیه که چه ROM کدی اجرا بشه و چه کدی رو لود کنه نداریم.
بگذریم.
به هرحال اول ROM code و بعد کدی که ROM code توی SRAM لود میکنه اجرا میشه. حداقل کاری که این کد دومی انجام میده، اینه که DRAM رو initialize میکنه و بعد بوت لودر اصلیمون رو توش لود میکنه و اجرا میکنه.
البته این روش قدیمی‌تریه که الان دیگه جواب نمیده و درست نیست.

درستش اینه که کد دومی DRAM رو initialize میکنه و یه فرموری به اسم TF-A رو به همراه بوت لودرمون توی DRAM لود میکنه.

درواقع TF-A یک Trusted Firmware اپن سورس هست که آرم ما رو مجبور کرده داشته باشیمش. البته به جز TF-A مدلهای دیگه ای از Trusted Firmware ها هم وجود دارن ولی معروف ترینشون اینه.

این TF-A به عنوان سومین کدی که داره اجرا میشه، توی secure world آرم اجرا میشه. Secure world توی آرم، یه چیزی خیلی شبیه به real mode توی اینتل هست.

نهایتا TF-A، بوت لودرمون رو که قبلا توسط کد مرحله دوممون توی DRAM لود شده رو اجرا میکنه و به این ترتیب به بوت لودر واقعی میرسیم.

بوت لودر معروف برای سیستم‌های امبدد، UBoot هست که توی پست بعد درموردش صحبت میکنم

#Linux
#EmbeddedLinux

UBoot

این بوت لودر اپن سورس، درحال حاضر پرکاربردترین بوت‌لودر در فضای امبدد لینوکس هست.

اگه همون مثال orangepi zero3 رو با تراشه allwinner در نظر بگیریم و بخوایم یه بوت لودر براش کامپایل کنیم، مراحل زیر رو باید انجام بدیم:

۱. آماده‌سازی تولچین مناسب برای کامپایل UBoot
۲. کامپایل TF-A
۲. تنظیم UBoot
۳. کامپایل UBoot
۴. نصب UBoot روی برد

مرحله اول:
خب ازونجایی که تراشمون هسته arm داره، باید با کامپایلر آرم uboot رو کامپایل کنیم تا به کدی برسیم که روی تراشه اجرا میشه.
علاوه بر این، یه کامپایلر خالی کافی نیست. باید یه تولچین مناسب داشته باشیم و اصطلاحا cross compilation انجام بدیم.

تولچین چیه؟
تولچین از موارد زیر تشکل میشه:
-binutils (binary utilities)
-kernel headers
-C/C++ libraries
-C/C++ compiler
-GDB debugger

برای اینکه به همچین چیزی برسیم، میتونیم از ابزاری به اسم crosstool-ng استفاده کنیم.

بعد از اینکه تولچینمون کامل شد، uboot رو کلون می‌کنیم، به آخرین تگش checkout می‌کنیم و برای کانفیگ شدنش، با استفاده از gnu make دستور زیر رو می‌زنیم:
make <board-name>_defconfig

به ‌این ترتیب، uboot برای بردمون تنظیم میشه. البته که menuconfig هم داریم و با اون هم میتونیم تنظیمات مدنظرمون رو اعمال کنیم.

بعد لازم داریم که باینری trusted firmware مون رو به UBoot بدیم. اینکار با export کردن یه متغیر محیطی انجام میشه.

همچنین باید مشخص کنیم که کراس کامپایلرمون چی هست که این هم با یه export دیگه انجام میشه

نهایتا با دستور make بوت لودر رو کامپایل می‌کنیم:
make -j <number of cores>

به این ترتیب یه فایل باینری که همون ایمیجی هست که داخلش کد TF-A و Bootloader وجود داره، ساخته شده. درواقع چندین باینری ساخته میشن که یکیش اینه.

حالا کافیه این ایمیج رو روی sd card مون burn کنیم و sd card رو روی برد بذاریم.
به این ترتیب بوت لودرمون رو راه انداختیم.

جزئیات کار رو نگفتم. اگه علاقه‌مندین، اسلاید‌های bootlin رو چک کنین.

توی سایت زیر هم مراحل کامپایل ساخت بوت لودر توسط uboot برای تراشه‌های allwinner توضیح داده شده:
https://docs.u-boot.org/en/stable/board/allwinner/sunxi.html

🔴 همونطور که قبلا در کانال قرار داده بودم، دو تا آسیب پذیری با شناسه ی CVE-2025-55182 و CVE-2025-66478 در React و Next.js کشف و اصلاح شدن که در جامعه ی امنیت بهشون React2Shell میگن. چون هم امکان اجرای کد رو به مهاجم میده و هم مثل Log4j، خیلی از زیرساختها و برنامه ها رو میتونن تحت تاثیر قرار بدن.

یسری PoC منتشر شده که هدفشون بیشتر تشخیص وجود React Server Components هستش. اما این برای تعیین قابلیت اکسپلویت کافی نیست و بسیاری از PoCهای عمومی قابل اعتماد نیستن.

یکی از راههای تشخیص React2Shell استفاده از Burp Suite هستش. برای اینکار میتونید از افزونه ی ActiveScan++ (v2.0.8) استفاده کنید که تست خودکار React2Shell رو روی برنامه‌های Next.js انجام میده.

اگه نیاز به تست دقیق و سفارشی دارید، میتونید از Bambda ویژه ی React2Shell استفاده کنید.

اگه نیاز دارید وضعیت React2Shell رو در چندین برنامه یا محیط بررسی کنید، Burp Suite DAST تشخیص خودکار و پیوسته رو از طریق ActiveScan++ (v2.0.8)، در مقیاس بزرگ ارائه میده.

جزییات بیشتر رو میتونید از اینجا بدست بیارید.

#آسیب_پذیری_امنیتی

#React #CVE #Nextjs #React2Shell

🆔 @onhex_ir
🌍 ONHEXGROUP (Official Links)