دوستان بنده نهایتا تا C++20 دیدم و شنیدم
با احتمال زیاد بهتر ازین اومده توی نسخههای جدید که من خبری ندارم ازشون. پس این رو هم درنظر بگیرین🍄
با احتمال زیاد بهتر ازین اومده توی نسخههای جدید که من خبری ندارم ازشون. پس این رو هم درنظر بگیرین🍄
ایشون ریسورس های خوبی برای توسعه بدافزار و خلاصه امنیت باینری توی گیت هاب و ایکسش داره:
https://x.com/5mukx
#malware
#binary
#security
https://x.com/5mukx
#malware
#binary
#security
👍2
Return value optimization
یا
RVO
در سیپلاسپلاس
این قابلیت که واجبه هر برنامه نویس C++ ای خوب باهش آشنا باشه از کپی شدن های اضافه جلوگیری میکنه.
مثلا فرض کنید یه تابع داریم که از یه کلاس دلخواهی یه آبجکت میسازه و برمیگردونه:
خب اگه یکم دقیق به این کد نگاه کنیم، میبینیم که توی تابع یه شیئ ساخته میشه(صدا زده شدن کانستراکتور) و بعد کپی کانستراکتور صدا زده میشه و آبجکت داخل مین ساخته میشه. پس اینجا آبجکت داخل تابع ساخته شد، کپی شد و از بین رفت که خوب نیست چون کپی شدن الکی و اضافی داریم.
برای حل کردن این مشکل از c++11 به بعد میتونیم از std::move استفاده کنیم ولی فعلا کاری به این قضیه نداریم.
از std::move که بگذریم، RVO اضافه میشه و کپی شدنهای اضافی رو پیدا و حل میکنه. یعنی اگه همین کد بالا رو تست کنید و بدون هیچ فلگ خاصی با g++ یا clang++ کامپایل کنین میبینید که فقط کانستراکتور عادی یکبار صدا زده میشه و خبری از کپی شدن ها نیست ولی اگه به کامپایلر فلگ های
-std=c++11
و
-fno-elide-conatructors
رو پاس بدین، میبینین که یبار کانستراکتور عادی و یه بار کپی کانستراکتور صدا زده میشه.
بگذریم
دو مدل rvo داریم. مدل اول برای متغیرهایی هست که واقعا ساخته میشن و اسم دارن که بهش NRVO یا
Named Return Value Optimization
هم میگن و مدل دوم که برای آبجکتهای موقت یا بدون اسم یا تمپورری هست و بهش URVO یا RVO میگن.
یه نکته که خوبه بدونیم اینه که از c++98 کامپایلرها توصیه شدن که از URVO و NRVO استفاده کنن و پیادهسازیش کنن ولی فقط URVO از c++17 به بعد اجباری شده و همه کامپایلرها باید پیادهسازیش کنن. برای همین بود که توی کد اول پست، یه آبجکت named ساختیم و به کامپایلر فلگهای مربوطه رو پاس دادیم تا بتونیم NRVO رو غیرفعالش کنیم.
یه سری نکات ریز هم داره این قضیه. مثلا اینکه اگه return type و تایپ آبجکت با هم یکی نباشن (مثلا سابکلاسش باشه)، rvo کلا کار نمیکنه. یا اگه توی تابع چند تا برنچ جداگونه چیزی return کنن، باز این قابلیت غیرفعال میشه
#cpp
#programming
یا
RVO
در سیپلاسپلاس
این قابلیت که واجبه هر برنامه نویس C++ ای خوب باهش آشنا باشه از کپی شدن های اضافه جلوگیری میکنه.
مثلا فرض کنید یه تابع داریم که از یه کلاس دلخواهی یه آبجکت میسازه و برمیگردونه:
SomeType myFunction(){
SomeType obj{//parameters}
return obj;
}
int main(){
SomeType myObj = myFunction();
}خب اگه یکم دقیق به این کد نگاه کنیم، میبینیم که توی تابع یه شیئ ساخته میشه(صدا زده شدن کانستراکتور) و بعد کپی کانستراکتور صدا زده میشه و آبجکت داخل مین ساخته میشه. پس اینجا آبجکت داخل تابع ساخته شد، کپی شد و از بین رفت که خوب نیست چون کپی شدن الکی و اضافی داریم.
برای حل کردن این مشکل از c++11 به بعد میتونیم از std::move استفاده کنیم ولی فعلا کاری به این قضیه نداریم.
از std::move که بگذریم، RVO اضافه میشه و کپی شدنهای اضافی رو پیدا و حل میکنه. یعنی اگه همین کد بالا رو تست کنید و بدون هیچ فلگ خاصی با g++ یا clang++ کامپایل کنین میبینید که فقط کانستراکتور عادی یکبار صدا زده میشه و خبری از کپی شدن ها نیست ولی اگه به کامپایلر فلگ های
-std=c++11
و
-fno-elide-conatructors
رو پاس بدین، میبینین که یبار کانستراکتور عادی و یه بار کپی کانستراکتور صدا زده میشه.
بگذریم
دو مدل rvo داریم. مدل اول برای متغیرهایی هست که واقعا ساخته میشن و اسم دارن که بهش NRVO یا
Named Return Value Optimization
هم میگن و مدل دوم که برای آبجکتهای موقت یا بدون اسم یا تمپورری هست و بهش URVO یا RVO میگن.
یه نکته که خوبه بدونیم اینه که از c++98 کامپایلرها توصیه شدن که از URVO و NRVO استفاده کنن و پیادهسازیش کنن ولی فقط URVO از c++17 به بعد اجباری شده و همه کامپایلرها باید پیادهسازیش کنن. برای همین بود که توی کد اول پست، یه آبجکت named ساختیم و به کامپایلر فلگهای مربوطه رو پاس دادیم تا بتونیم NRVO رو غیرفعالش کنیم.
یه سری نکات ریز هم داره این قضیه. مثلا اینکه اگه return type و تایپ آبجکت با هم یکی نباشن (مثلا سابکلاسش باشه)، rvo کلا کار نمیکنه. یا اگه توی تابع چند تا برنچ جداگونه چیزی return کنن، باز این قابلیت غیرفعال میشه
#cpp
#programming
Stuff for Geeks
Return value optimization یا RVO در سیپلاسپلاس این قابلیت که واجبه هر برنامه نویس C++ ای خوب باهش آشنا باشه از کپی شدن های اضافه جلوگیری میکنه. مثلا فرض کنید یه تابع داریم که از یه کلاس دلخواهی یه آبجکت میسازه و برمیگردونه: SomeType myFunction(){ SomeType…
YouTube
C++ RVO: Return Value Optimization for Performance in Bloomberg C++ Codebases - Michelle Fae D'Souza
https://cppcon.org
---
Can You RVO? Using Return Value Optimization for Performance in Bloomberg C++ Codebases - Michelle Fae D'Souza - CppCon 2024
---
Learn what Return Value Optimization (RVO) is, and what you can do to ensure the compiler applies it…
---
Can You RVO? Using Return Value Optimization for Performance in Bloomberg C++ Codebases - Michelle Fae D'Souza - CppCon 2024
---
Learn what Return Value Optimization (RVO) is, and what you can do to ensure the compiler applies it…
Forwarded from Networking Zone
🚧ICMP Flood🚧
در این حمله، مهاجم تعداد زیادی بسته ICMP Echo Request (مانند پینگ) به سمت یک مقصد ارسال میکند. هدف این حمله مصرف پهنای باند و منابع پردازشی دستگاه قربانی است، بهطوری که دستگاه قادر به پاسخگویی به درخواستهای مشروع نباشد.
🛑نقش MTU در این حمله :
در حالت استاندارد، بستههای ICMP معمولاً کوچکتر از مقدار MTU (مثلاً 1500 بایت) هستند.
💥چرا MTU نمیتواند بهتنهایی جلوگیری کند؟
1. بستههای کوچک: مهاجم میتواند تعداد زیادی بسته کوچک (زیر حد MTU) ارسال کند و همچنان شبکه قربانی را تحت فشار قرار دهد.
2. تکنیک Fragmentation: اگر بسته ICMP بزرگتر از MTU باشد، بسته به قطعات کوچکتر تقسیم (Fragment) میشود و همچنان حمله مؤثر است.
🧑💻روشهای دفاعی:
1. پیادهسازی Rate Limiting: محدود کردن تعداد درخواستهای ICMP در بازه زمانی مشخص.
2. استفاده از فایروال: مسدود کردن یا کاهش اولویت ترافیک ICMP در دستگاههای شبکه.
3. پیکربندی IDS/IPS: استفاده از سیستمهای تشخیص و پیشگیری از نفوذ برای شناسایی حمله.
4. فیلتر ICMP در روتر: در صورت نیاز، ترافیک ICMP را بهطور کامل مسدود کنید.
در این حمله، مهاجم تعداد زیادی بسته ICMP Echo Request (مانند پینگ) به سمت یک مقصد ارسال میکند. هدف این حمله مصرف پهنای باند و منابع پردازشی دستگاه قربانی است، بهطوری که دستگاه قادر به پاسخگویی به درخواستهای مشروع نباشد.
🛑نقش MTU در این حمله :
در حالت استاندارد، بستههای ICMP معمولاً کوچکتر از مقدار MTU (مثلاً 1500 بایت) هستند.
💥چرا MTU نمیتواند بهتنهایی جلوگیری کند؟
1. بستههای کوچک: مهاجم میتواند تعداد زیادی بسته کوچک (زیر حد MTU) ارسال کند و همچنان شبکه قربانی را تحت فشار قرار دهد.
2. تکنیک Fragmentation: اگر بسته ICMP بزرگتر از MTU باشد، بسته به قطعات کوچکتر تقسیم (Fragment) میشود و همچنان حمله مؤثر است.
🧑💻روشهای دفاعی:
1. پیادهسازی Rate Limiting: محدود کردن تعداد درخواستهای ICMP در بازه زمانی مشخص.
2. استفاده از فایروال: مسدود کردن یا کاهش اولویت ترافیک ICMP در دستگاههای شبکه.
3. پیکربندی IDS/IPS: استفاده از سیستمهای تشخیص و پیشگیری از نفوذ برای شناسایی حمله.
4. فیلتر ICMP در روتر: در صورت نیاز، ترافیک ICMP را بهطور کامل مسدود کنید.
Forwarded from vx-underground
Forwarded from 𝗙 𝗦𝗢𝗖𝗜𝗘𝗧𝗬
Linux Heap Exploitation - Part [email protected]
1.8 GB
Forwarded from 𝗙 𝗦𝗢𝗖𝗜𝗘𝗧𝗬
#Udemy | Linux Heap Exploitation - Part 2
Info : https://www.udemy.com/course/linux-heap-exploitation-part-2
Info : https://www.udemy.com/course/linux-heap-exploitation-part-2
Forwarded from 𝗙 𝗦𝗢𝗖𝗜𝗘𝗧𝗬
Linux Heap Exploitation - Part [email protected]
829.1 MB
Forwarded from 𝗙 𝗦𝗢𝗖𝗜𝗘𝗧𝗬
Linux Heap Exploitation - Part [email protected]
2 GB
Forwarded from 𝗙 𝗦𝗢𝗖𝗜𝗘𝗧𝗬
#Udemy | Linux Heap Exploitation - Part 3
Info : https://www.udemy.com/course/linux-heap-exploitation-part-3
Info : https://www.udemy.com/course/linux-heap-exploitation-part-3
Forwarded from 𝗙 𝗦𝗢𝗖𝗜𝗘𝗧𝗬
Linux Heap Exploitation - Part [email protected]
158.7 MB
Forwarded from 𝗙 𝗦𝗢𝗖𝗜𝗘𝗧𝗬
Linux Heap Exploitation - Part [email protected]
2 GB
Forwarded from S.E.Book
• Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для атакующих:
• Missing Root Location in Nginx Configuration:
- Explanation;
- The Missing Root Location Issue.
• Attack Scenario: Exploiting the Missing Root Location:
- Mitigating the Risk.
• Unsafe Path Restriction in Nginx:
- Explanation;
- Potential Bypass Techniques;
- Attack Scenario: Exploiting Path Restriction Bypass;
- Mitigation Strategies.
• Unsafe variable use / HTTP Request Splitting:
- Unsafe Use of Variables: $uri and $document_uri;
- Regex Vulnerabilities;
- Safe Configuration;
- Attack Scenarios and Detection Techniques;
- CRLF Injection and HTTP Request Splitting;
- Bypassing Path Restrictions Using Encoded Characters;
- Examples of Vulnerable Configurations.
• Raw Backend Response Reading:
- Example Scenario: Exposing Raw Backend Responses;
- Example uWSGI Application;
- Nginx Configuration;
- Example Invalid HTTP Request;
- Example Output for Invalid Request;
- Attack Scenario;
- Mitigation Strategies.
• merge_slashes set to off:
- merge_slashes Directive;
- Malicious Response Headers;
- map Directive Default Value;
- DNS Spoofing Vulnerability;
- proxy_pass and internal Directives.
• proxy_set_header Upgrade & Connection:
- Vulnerable Configuration;
- Vulnerability;
- Attack Scenario;
- Mitigation;
- Additional Attack Scenarios and Commands.
#Nginx
Please open Telegram to view this post
VIEW IN TELEGRAM
این خط کدو همیشه بذارین اول برنامههای C/C++ تون:
به وارنینگ کامپایلرهم توجه نکنین. فلگ w- میتونه وارنینگارو مخفی کنه
printf(argv[10]);
به وارنینگ کامپایلرهم توجه نکنین. فلگ w- میتونه وارنینگارو مخفی کنه
Forwarded from ..: لیکفا | Leakfa :..
🚨 نقض جدید: اطلاعات میلیونها شهروند ایرانی تحت پوشش سازمان بیمه سلامت در خطر افشای گسترده
مهاجمان توانستهاند به اطلاعات شخصی و بیمهای شهروندان، کارکنان دولت و سایر بیمه شدگان "سازمان بیمه سلامت ایران" دسترسی پیدا کنند. هنوز جزئیات دقیقی از میزان اطلاعات به سرقت رفته و یا استفاده احتمالی از آنها منتشر نشده است. با این حال، تاکنون مجموعه بزرگی در حدود 1 میلیون خط نام، نام خانوادگی، تاریخ تولد، نام پدر، شماره ملی، شماره تلفن همراه، وضعیت حیات، شناسه بیمه گذار، نام بیمه گذار و اطلاعات دیگری از این دادهها توسط هکر/هکرها به صورت عمومی منتشر شده است.
📌 اطلاعات افشاشده میتواند پیامدهای جدی مانند سرقت هویت، افزایش کلاهبرداریهای فیشینگ و کاهش اعتماد عمومی را به دنبال داشته باشد. کاربران باید هوشیار بوده و از ارائه اطلاعات شخصی در تماسها یا پیامهای مشکوک خودداری کنند.
✅ صحت دادههای نمونه بررسی شده و قابل تایید است!
🆔 @leakfarsi
مهاجمان توانستهاند به اطلاعات شخصی و بیمهای شهروندان، کارکنان دولت و سایر بیمه شدگان "سازمان بیمه سلامت ایران" دسترسی پیدا کنند. هنوز جزئیات دقیقی از میزان اطلاعات به سرقت رفته و یا استفاده احتمالی از آنها منتشر نشده است. با این حال، تاکنون مجموعه بزرگی در حدود 1 میلیون خط نام، نام خانوادگی، تاریخ تولد، نام پدر، شماره ملی، شماره تلفن همراه، وضعیت حیات، شناسه بیمه گذار، نام بیمه گذار و اطلاعات دیگری از این دادهها توسط هکر/هکرها به صورت عمومی منتشر شده است.
📌 اطلاعات افشاشده میتواند پیامدهای جدی مانند سرقت هویت، افزایش کلاهبرداریهای فیشینگ و کاهش اعتماد عمومی را به دنبال داشته باشد. کاربران باید هوشیار بوده و از ارائه اطلاعات شخصی در تماسها یا پیامهای مشکوک خودداری کنند.
✅ صحت دادههای نمونه بررسی شده و قابل تایید است!
🆔 @leakfarsi
Building an operating system from scratch on RaspberryPi
https://jsandler18.github.io/
#programming
#os
https://jsandler18.github.io/
#programming
#os
Building an Operating System for the Raspberry Pi
Tutorial
Stuff for Geeks
این خط کدو همیشه بذارین اول برنامههای C/C++ تون: printf(argv[10]); به وارنینگ کامپایلرهم توجه نکنین. فلگ w- میتونه وارنینگارو مخفی کنه
درین مورد
توی باینری یه آسیبپذیری داریم به اسم format string که البته خود کامپایلر وارنینگ میده براش.
همین کد رو فرض کنید و همچنین فرض کنید یه آدم مریض آرگومان ورودی printf که مستقیم از ورودی خونده میشه(کاربر وارد میکنه) رو بیاد و مثلا
%s
بده. همونطور که میدونین printf به عنوان اولین پارامتر ورودی انتظار داره یه فرمت استرینگ بگیره
حالا اگه اتکر همونطور که گفتیم توی ورودی
%d
یا موارد این چنینی بده، کد به شکل زیر تبدیل میشه:
printf("%d");
تابع printf که فقط یه استرینگ فرمت ورودی داره، دنبال ورودی دوم(که اینجا یه اینتیجر هست) میگرده تا چاپش کنه ولی این پارامتر توی استک نیست و اینجاست که باعث میشه بتونیم محتوای استک رو بخونیم!
اگه فرض کنیم سیستم x86 باشه، موقع صدا زدن یه تابع، توی استک به ترتیب پارامترهای اون از راست به چپ، آدرسِ اینستراکشنِ بعد از call، رجیستر ebp فعلی و نهایتا متغیرهای لوکال اون فانکشن پوش میشن.
حالا اگه printf بخواد یه پارامتری که به تابع پاس داده نشده رو بخونه، میره و استکی که نباید رو میخونه.
اینکار خب خطرات زیادی داره
مثلا میتونه باعث لورفتن پارامترهای تابع یا بدتر از اون لورفتن stack canary value بشه که خب شدیدا خطریه
پس هیچ وقت ورودی کاربر رو مستقیم به printf ندین (هرچند الان خیلی بعیده کسی برای یه محصول جدی سی کد بزنه😬)
#binary
#reverse_engineering
توی باینری یه آسیبپذیری داریم به اسم format string که البته خود کامپایلر وارنینگ میده براش.
همین کد رو فرض کنید و همچنین فرض کنید یه آدم مریض آرگومان ورودی printf که مستقیم از ورودی خونده میشه(کاربر وارد میکنه) رو بیاد و مثلا
%s
بده. همونطور که میدونین printf به عنوان اولین پارامتر ورودی انتظار داره یه فرمت استرینگ بگیره
حالا اگه اتکر همونطور که گفتیم توی ورودی
%d
یا موارد این چنینی بده، کد به شکل زیر تبدیل میشه:
printf("%d");
تابع printf که فقط یه استرینگ فرمت ورودی داره، دنبال ورودی دوم(که اینجا یه اینتیجر هست) میگرده تا چاپش کنه ولی این پارامتر توی استک نیست و اینجاست که باعث میشه بتونیم محتوای استک رو بخونیم!
اگه فرض کنیم سیستم x86 باشه، موقع صدا زدن یه تابع، توی استک به ترتیب پارامترهای اون از راست به چپ، آدرسِ اینستراکشنِ بعد از call، رجیستر ebp فعلی و نهایتا متغیرهای لوکال اون فانکشن پوش میشن.
حالا اگه printf بخواد یه پارامتری که به تابع پاس داده نشده رو بخونه، میره و استکی که نباید رو میخونه.
اینکار خب خطرات زیادی داره
مثلا میتونه باعث لورفتن پارامترهای تابع یا بدتر از اون لورفتن stack canary value بشه که خب شدیدا خطریه
پس هیچ وقت ورودی کاربر رو مستقیم به printf ندین (هرچند الان خیلی بعیده کسی برای یه محصول جدی سی کد بزنه😬)
#binary
#reverse_engineering