Forwarded from Linuxor ?
خیلیا زبان برنامه نویسی اسمبلی رو معمولاً برای نوشتن کدهای کوچیک یا بهینهسازی توابع میشناسن، این شخص اومده بهتون نشون بده چطوری میشه چیزای گرافیکی باهاش بسازین
کار سختی نیست فقط باید حوصله کنید بخونیدش، چیزای خوبی یاد میگیرین :
gaultier.github.io/blog/x11_x64.html
@Linuxor
کار سختی نیست فقط باید حوصله کنید بخونیدش، چیزای خوبی یاد میگیرین :
gaultier.github.io/blog/x11_x64.html
@Linuxor
Forwarded from 🕸 Articles
JS for Hacker-Volume 1.pdf
9.2 MB
Forwarded from 🕸 Articles
این کتاب رایگان هست و هیچ قیمتی براش نذاشتم. اما اگه دوست داشتید از من حمایت کنید، میتونید از این لینک استفاده کنید:
https://daramet.com/web_articles
همچنین میتونید با به اشتراک گذاشتن کتاب، کمک کنید که بیشتر دیده بشه.
https://daramet.com/web_articles
همچنین میتونید با به اشتراک گذاشتن کتاب، کمک کنید که بیشتر دیده بشه.
Daramet
درگاه حمایت مالی دارمت
درگاه حمایت مالی دارمت به شما کمک میکنه از مخاطب ها، دنبال کنندهها و طرفدارات با امکانات گسترده دونیت دریافت کنی.
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
و
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
احساس میکنم کم کم باید بلاگ بزنم😂
اینجا نمیشه درست ویراستاری کرد
اینجا نمیشه درست ویراستاری کرد
👍2
Forwarded from OS Internals (Abolfazl Kazemi)
📢 انتشار فصل ششم دوره 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
ℹ️ مقدمات برنامهنویسی 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
YouTube
P06-01) Why and What of Return Oriented Programming [PER]
مقدمهای بر ROP دلیل پیدایش آن، مفهوم «گجت»، روش ساختن chain و اینکه این تکنیک چگونه محدودیتهای امنیتی مثل NX را دور میزند.
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
یه چند وقته درگیر اینم که چجوری لینوکس خودم رو روی یه برد کاستوم شده پیاده کنم و بسازم.
برد کاستوم شده که خب ندارم ولی با 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
Stuff for Geeks
Embedded linux یه چند وقته درگیر اینم که چجوری لینوکس خودم رو روی یه برد کاستوم شده پیاده کنم و بسازم. برد کاستوم شده که خب ندارم ولی با orangepi zero3 کار رو یه مقدار جلو بردم و میخوام تجربم رو به اشتراک بذارم. اول از همه باید ببینیم چه مواردی لازمه تا…
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
این بوت لودر اپن سورس، درحال حاضر پرکاربردترین بوتلودر در فضای امبدد لینوکس هست.
اگه همون مثال 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
Forwarded from OnHex
🔴 همونطور که قبلا در کانال قرار داده بودم، دو تا آسیب پذیری با شناسه ی 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)
یسری 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)
portswigger.net
Active Scan++
Extends Burp's active and passive scanning capabilities.
❤1
Forwarded from OS Internals (Abolfazl Kazemi)
📢 انتشار فصل هفتم دوره Linux Exploit Development
ℹ️ جزئیات ساختار فایلهای ELF. مشاهدهی این فصل به علاقهمندان به Internal لینوکس نیز توصیه میشود.
📚 در این فصل بهصورت عمیق با ساختار فایلهای ELF آشنا میشویم؛ فرمت استانداردی که تمام باینریها، کتابخانهها و ابزارهای لینوکسی بر پایه آن ساخته شدهاند.
درک صحیح ELF نه تنها برای تحلیل آسیبپذیریها و نوشتن اکسپلویتها ضروری است، بلکه برای علاقهمندان Linux Internals و متخصصان امنیت نیز یک مهارت کلیدی محسوب میشود.
📚در این فصل بخشهای مختلف ELF شامل سرآیندها، جدولهای رشته، Program Headerها و Section Headerها را بررسی میکنیم و سپس وارد دنیای لینکدهی پویا میشویم. در نهایت نحوهی عملکرد GOT/PLT و اینکه سیستمعامل چگونه توابع کتابخانهای را هنگام اجرا resolve میکند را یاد میگیرید — دانشی که پایهی بسیاری از تکنیکهای تحلیل و اکسپلویتنویسی پیشرفته است، مثل ret2plt و ret2got.
✍️ لینک ویدئوهای فصل ۷ در یوتیوب:
P07-01) ELF Introduction
P07-02) ELF Header
P07-03) ELF Entrypoint
P07-04) Program Headers
P07-05) Playing with Program Headers
P07-06) String Table
P07-07) Section Headers
P07-08) Dynamic Linking
P07-09) GOT and PLT
P07-10) Resolving library functions using PLT GOT
✍️ لینک ویدئوهای فصل ۷ در آپارات:
https://aparat.com/v/ajsd66x
https://aparat.com/v/wzj6d2e
https://aparat.com/v/lyi132n
https://aparat.com/v/oxp9p38
https://aparat.com/v/mql32hk
https://aparat.com/v/uidj0gv
https://aparat.com/v/axwxxgp
https://aparat.com/v/rjwj757
https://aparat.com/v/flg5k5l
https://aparat.com/v/awd2k2c
#linux #exploitdev #gdb #ELF #binary_analysis #internals #got #plt #linking
ℹ️ جزئیات ساختار فایلهای ELF. مشاهدهی این فصل به علاقهمندان به Internal لینوکس نیز توصیه میشود.
📚 در این فصل بهصورت عمیق با ساختار فایلهای ELF آشنا میشویم؛ فرمت استانداردی که تمام باینریها، کتابخانهها و ابزارهای لینوکسی بر پایه آن ساخته شدهاند.
درک صحیح ELF نه تنها برای تحلیل آسیبپذیریها و نوشتن اکسپلویتها ضروری است، بلکه برای علاقهمندان Linux Internals و متخصصان امنیت نیز یک مهارت کلیدی محسوب میشود.
📚در این فصل بخشهای مختلف ELF شامل سرآیندها، جدولهای رشته، Program Headerها و Section Headerها را بررسی میکنیم و سپس وارد دنیای لینکدهی پویا میشویم. در نهایت نحوهی عملکرد GOT/PLT و اینکه سیستمعامل چگونه توابع کتابخانهای را هنگام اجرا resolve میکند را یاد میگیرید — دانشی که پایهی بسیاری از تکنیکهای تحلیل و اکسپلویتنویسی پیشرفته است، مثل ret2plt و ret2got.
✍️ لینک ویدئوهای فصل ۷ در یوتیوب:
P07-01) ELF Introduction
P07-02) ELF Header
P07-03) ELF Entrypoint
P07-04) Program Headers
P07-05) Playing with Program Headers
P07-06) String Table
P07-07) Section Headers
P07-08) Dynamic Linking
P07-09) GOT and PLT
P07-10) Resolving library functions using PLT GOT
✍️ لینک ویدئوهای فصل ۷ در آپارات:
https://aparat.com/v/ajsd66x
https://aparat.com/v/wzj6d2e
https://aparat.com/v/lyi132n
https://aparat.com/v/oxp9p38
https://aparat.com/v/mql32hk
https://aparat.com/v/uidj0gv
https://aparat.com/v/axwxxgp
https://aparat.com/v/rjwj757
https://aparat.com/v/flg5k5l
https://aparat.com/v/awd2k2c
#linux #exploitdev #gdb #ELF #binary_analysis #internals #got #plt #linking
YouTube
P07-03) ELF Entrypoint [PER]
بررسی نقطه ورودی برنامه و چگونگی شروع اجرای یک باینری.
🙈1
Forwarded from 𝕊𝕠𝕙𝕖𝕚𝕝
منابع رایگان و فارسی یادگیری FPGA
FPGA
محمد صادق صدری
پلی لیست
فرااندیش
محمدرضا بیگی
زهرا مختاری
زهرا مختاری ۲
زهرا مختاری ۳
Micro Lab
Mico Lab 2
پازج
Verilog
زین العابدین نوابی
محمدرضا موحدین
وریلاگ صفر تا صد با بیان ساده
Mamin_kazemii
Zync.ir
VHDL
Hossein Rostami
Mamin_kazemii
Vivado
Zynq.ir
Mamin_kazemii
مدار منطقی
زین العابدین نوابی
زین العابدین نوابی
Mamin_kazemii
Zync
zync.ir
Zync FPGATutorial
systemC
زین العابدین نوابی
#fpga
#verilog
#vhdl
#course
#farsi
@Embedded_geek
FPGA
محمد صادق صدری
پلی لیست
فرااندیش
محمدرضا بیگی
زهرا مختاری
زهرا مختاری ۲
زهرا مختاری ۳
Micro Lab
Mico Lab 2
پازج
Verilog
زین العابدین نوابی
محمدرضا موحدین
وریلاگ صفر تا صد با بیان ساده
Mamin_kazemii
Zync.ir
VHDL
Hossein Rostami
Mamin_kazemii
Vivado
Zynq.ir
Mamin_kazemii
مدار منطقی
زین العابدین نوابی
زین العابدین نوابی
Mamin_kazemii
Zync
zync.ir
Zync FPGATutorial
systemC
زین العابدین نوابی
#fpga
#verilog
#vhdl
#course
#farsi
@Embedded_geek
🔥1
کد وریلاگ پروسسور OR1200 که یک پردازنده اپن سورس برای معماری RISC اپن سورس OR1000 هست را میتوانید در ریپوزیتوری زیر مشاهده کنید:
https://github.com/openrisc/or1200
https://github.com/openrisc/or1200
GitHub
GitHub - openrisc/or1200: OpenRISC 1200 implementation
OpenRISC 1200 implementation. Contribute to openrisc/or1200 development by creating an account on GitHub.
Stuff for Geeks
کد وریلاگ پروسسور OR1200 که یک پردازنده اپن سورس برای معماری RISC اپن سورس OR1000 هست را میتوانید در ریپوزیتوری زیر مشاهده کنید: https://github.com/openrisc/or1200
جالبه بدونید که اکثر SoC ها و پردازندهها داخل خودشون علاوه بر CPU یک میکروکنترلر هم دارن. اینکه چرا همچین چیزی باید وجود داشته باشه جای بحث داره ولی چیزی که گفته میشه اینه که این میکروکنترلر وظیفه انجام کارهایی رو داره که CPU اصلی نباید ازشون خبری داشته باشه یا نباید بتونه کنترلشون کنه. مثلا بردن CPU به حالت کم مصرف و IDLE. اصطلاحا به این میکروها coprocessor یا System Control Processor (SCP) هم گفته میشه.
توی پردازنده های Allwinner هم کنار CPU آرم اصلی یدونه ازین میکروکنترلرها قرار داره که مثلا توی سری H3 به بعد، اسمش AR100 هست و معماریش OR1000 یا همون OpenRISC 1000 هست که وظیفه بردن CPU به حالتهای کممصرف رو داره.
جالبه که میشه از این میکروکنترلر کلا به عنوان یه میکروی مجزا استفاده کرد!
خود Allwinner داکیومنتی درمورد این میکرو نمیده و فقط یه firmware blob میده ولی میتونید در ریپوزیتوری زیر یه firmware اپن سورس که کار همین firmware blob رو انجام میده، ببینید:
https://github.com/openrisc/or1200
توی پردازنده های Allwinner هم کنار CPU آرم اصلی یدونه ازین میکروکنترلرها قرار داره که مثلا توی سری H3 به بعد، اسمش AR100 هست و معماریش OR1000 یا همون OpenRISC 1000 هست که وظیفه بردن CPU به حالتهای کممصرف رو داره.
جالبه که میشه از این میکروکنترلر کلا به عنوان یه میکروی مجزا استفاده کرد!
خود Allwinner داکیومنتی درمورد این میکرو نمیده و فقط یه firmware blob میده ولی میتونید در ریپوزیتوری زیر یه firmware اپن سورس که کار همین firmware blob رو انجام میده، ببینید:
https://github.com/openrisc/or1200
GitHub
GitHub - openrisc/or1200: OpenRISC 1200 implementation
OpenRISC 1200 implementation. Contribute to openrisc/or1200 development by creating an account on GitHub.
👍1