Forwarded from Source Chat (main one)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🪄࿐. ݁₊ 🌸 Ame 🎀
😁5👍1
Forwarded from Infosec Fortress
Zhang Yunhai - BYPASS CONTROL FLOW GUARD COMPREHENSIVELY - Blackhat
#binary
#exploitation
———
🆔 @Infosec_Fortress
#binary
#exploitation
———
🆔 @Infosec_Fortress
❤5👍3
Forwarded from An Inspired Engineer
کرنل چطور میدونه توی این لحظه کدوم پروسس روی یک هستهی cpu در حال اجراست؟
کرنل تسک(پروسس)هایی که در حال اجرا هستن رو توی یک Linked List به صورت double به اسم task list نگهداری میکنه، ساختمون داده ای که این linked list نگهداری میکنه task_struct هست که نسبتا بزرگه و تمامی اطلاعاتی که کرنل نیاز داره تا بروی پروسس ها context switch انجام بده یا چه فایل هایی توسط این پروسس بازه، وضعیت پروسس چیه، فضای آدرس حافظه کجاست و ... رو توی خودش داره.
نکته:
هر پروسس توی فضای کرنل یک استک داره که کرنل اطلاعات مربوط به این پروسس، ادرس برگشت متد ها، متغیرهای محلی و... رو توش نگهمیداره. و توی معماری x86 کرنل پوینتر ساختمون داده task_struct متعلق به هر پروسس رو توی انتهای استک همون پروسس میزاره، یعنی اگه از انتهای استک یک پروسس به عقب برگردیم به اطلاعات اون پروسس دسترسی داریم(البته که توی فضای کرنل).
خب حالا خود کرنل چطور به تسکی که الان در حال اجراست میرسه تا بتونه اصلا به task_struct دسترسی داشته باشه؟
همونطور که بالاتر گفتم لیست تسک ها توی یک linked list نگهداری میشن و برای اینکه بتونیم تسکی که در حال اجراست رو پیدا کنیم باید کل لیست رو بگردیم، شاید روی ماشین های خونگی به چشم نیاد ولی روی سرورهایی که چندین هزار پروسس میتونن داشته باشن O(n) هزینهی بالایی محسوب میشه. راه حل؟ کرنل میاد برای اینکه تسک درحال اجرا رو پیدا کنه از ماکروی current استفاده میکنه که اون هم متد current_thread_info() رو کال میکنه. حالا با توجه به معماری یا ادرس این ساختمون داده روی یکی از رجیستر های cpu میزاره. یعنی دیگه نیازی نیست کل لیست رو بگردیم.
پیاده سازی این متد به معماری سخت افزار وابسته اس، برای مثال توی ماشین های power pc IBM رو اجرا میکنند کرنل این اطلاعات رو توی رجیستر r2 نگهداری میکنه و از طریق اسمبلی بهش دسترسی داره:
حالا شاید بگین که اوکی ما دیگه چه نیازی به لیست داریم وقتی اطلاعات توی رجیستر وجود داره؟
در حقیقت لیست برای اینه که scheduler بدونه تسک بعدی متعلق به کیه و آیا باید اجرا بشه یا نه؟! اینجا برای انتخاب کردن تسک بعدی کرنل پارامترای اون پروسس رو چک میکنه که مهمترینشون state و priority هست، بعد از اینکه تسک بعدی انتخاب شد، اطلاعات تسک فعلی روی استک نوشته میشه و اطلاعات تسک بعدی روی رجیستر بارگیری میشه.
جمع بندی بخوام بکنم میشه:
- زمانی که پروسس جدید با fork یا clone ساخته میشه کرنل کپی task_struct از parent پروسس جدید هست رو توی task list که یک linked list گلوبال توی فضای کرنل هست اضافه میکنه.
- ماژول scheduler میاد و بر اساس اولویت و پارامتر های دیگه بین پروسس ها برای هر هستهی cpu عملیات context-switching رو انجام میده ولی قبلش مقدار جای فعلی استک، رجیسترهای cpu و وضعیت پروسس رو توی task_struct ذخیره کنه و بعد از انتخاب عملیات context swithing رو انجام بده.
- کرنل باید پوینتر ماکروی current رو به روز کنه تا به task_struct تسک جدید اشاره کنه و این ماکرو از طریق رجیسترهای cpu با سرعت بالا به task_struct دسترسی پیدا میکنه.
- وضعیت تسک جدید توی رجیسترهای cpu و از استک بارگیری میشه.
پس جواب ما برای سوال: کرنل چطور میدونه توی این لحظه کدوم پروسس روی یک هستهی cpu در حال اجراست؟ میشه اینکه کرنل اطلاعات رو توی یک لینک لیست نگهداری میکنه و پوینتر تسک فعلی رو هم برای اینکه O(n) هزینه نکنه از رجیستر میخونه.
منبع ۱
منبع ۲
@knowpow
کرنل تسک(پروسس)هایی که در حال اجرا هستن رو توی یک Linked List به صورت double به اسم task list نگهداری میکنه، ساختمون داده ای که این linked list نگهداری میکنه task_struct هست که نسبتا بزرگه و تمامی اطلاعاتی که کرنل نیاز داره تا بروی پروسس ها context switch انجام بده یا چه فایل هایی توسط این پروسس بازه، وضعیت پروسس چیه، فضای آدرس حافظه کجاست و ... رو توی خودش داره.
نکته:
هر پروسس توی فضای کرنل یک استک داره که کرنل اطلاعات مربوط به این پروسس، ادرس برگشت متد ها، متغیرهای محلی و... رو توش نگهمیداره. و توی معماری x86 کرنل پوینتر ساختمون داده task_struct متعلق به هر پروسس رو توی انتهای استک همون پروسس میزاره، یعنی اگه از انتهای استک یک پروسس به عقب برگردیم به اطلاعات اون پروسس دسترسی داریم(البته که توی فضای کرنل).
خب حالا خود کرنل چطور به تسکی که الان در حال اجراست میرسه تا بتونه اصلا به task_struct دسترسی داشته باشه؟
همونطور که بالاتر گفتم لیست تسک ها توی یک linked list نگهداری میشن و برای اینکه بتونیم تسکی که در حال اجراست رو پیدا کنیم باید کل لیست رو بگردیم، شاید روی ماشین های خونگی به چشم نیاد ولی روی سرورهایی که چندین هزار پروسس میتونن داشته باشن O(n) هزینهی بالایی محسوب میشه. راه حل؟ کرنل میاد برای اینکه تسک درحال اجرا رو پیدا کنه از ماکروی current استفاده میکنه که اون هم متد current_thread_info() رو کال میکنه. حالا با توجه به معماری یا ادرس این ساختمون داده روی یکی از رجیستر های cpu میزاره. یعنی دیگه نیازی نیست کل لیست رو بگردیم.
پیاده سازی این متد به معماری سخت افزار وابسته اس، برای مثال توی ماشین های power pc IBM رو اجرا میکنند کرنل این اطلاعات رو توی رجیستر r2 نگهداری میکنه و از طریق اسمبلی بهش دسترسی داره:
register struct task_struct *current asm ("r2");
حالا شاید بگین که اوکی ما دیگه چه نیازی به لیست داریم وقتی اطلاعات توی رجیستر وجود داره؟
در حقیقت لیست برای اینه که scheduler بدونه تسک بعدی متعلق به کیه و آیا باید اجرا بشه یا نه؟! اینجا برای انتخاب کردن تسک بعدی کرنل پارامترای اون پروسس رو چک میکنه که مهمترینشون state و priority هست، بعد از اینکه تسک بعدی انتخاب شد، اطلاعات تسک فعلی روی استک نوشته میشه و اطلاعات تسک بعدی روی رجیستر بارگیری میشه.
جمع بندی بخوام بکنم میشه:
- زمانی که پروسس جدید با fork یا clone ساخته میشه کرنل کپی task_struct از parent پروسس جدید هست رو توی task list که یک linked list گلوبال توی فضای کرنل هست اضافه میکنه.
- ماژول scheduler میاد و بر اساس اولویت و پارامتر های دیگه بین پروسس ها برای هر هستهی cpu عملیات context-switching رو انجام میده ولی قبلش مقدار جای فعلی استک، رجیسترهای cpu و وضعیت پروسس رو توی task_struct ذخیره کنه و بعد از انتخاب عملیات context swithing رو انجام بده.
- کرنل باید پوینتر ماکروی current رو به روز کنه تا به task_struct تسک جدید اشاره کنه و این ماکرو از طریق رجیسترهای cpu با سرعت بالا به task_struct دسترسی پیدا میکنه.
- وضعیت تسک جدید توی رجیسترهای cpu و از استک بارگیری میشه.
پس جواب ما برای سوال: کرنل چطور میدونه توی این لحظه کدوم پروسس روی یک هستهی cpu در حال اجراست؟ میشه اینکه کرنل اطلاعات رو توی یک لینک لیست نگهداری میکنه و پوینتر تسک فعلی رو هم برای اینکه O(n) هزینه نکنه از رجیستر میخونه.
منبع ۱
منبع ۲
@knowpow
👍6❤5🤣2👏1🍾1
👍3❤1👎1
(In)direct Syscalls: A journey from high to low
syllabus:
All the theory and playbooks for the exercises can be found in the wiki, which together with the prepared POCs is the heart of this project. The POCs for the exercises can be found here on the main page.
https://github.com/VirtualAlllocEx/DEFCON-31-Syscalls-Workshop.git
#redteam #malware_dev
RedOps | Red Team Village | DEF CON 31
syllabus:
01: Introduction and Abstract
02: Prerequistes
03: Chapter 1 | Windows NT Basics
04: Chapter 2 | Windows OS System Calls
05: Chapter 2 | LAB Exercise Playbook
06: Chapter 3 | Concept of Direct Syscalls
07: Chapter 4 | Win32 APIs
08: Chapter 4 | LAB Exercise Playbook
09: Chapter 5 | Native APIs
10: Chapter 5 | LAB Exercise Playbook
11: Chapter 6 | Direct Syscalls
12: Chapter 6 | LAB Exercise Playbook
13: Chapter 7 | Indirect Syscalls
14: Chapter 7 | LAB Exercise Playbook
All the theory and playbooks for the exercises can be found in the wiki, which together with the prepared POCs is the heart of this project. The POCs for the exercises can be found here on the main page.
https://github.com/VirtualAlllocEx/DEFCON-31-Syscalls-Workshop.git
#redteam #malware_dev
❤6👍2👾2
Forwarded from 1N73LL1G3NC3
TokenAssignor
This tool tries to steal token from a specified process and execute a token assigned process. Most of methods require administrative privileges.
Currently, 4 methods are implemented:
This tool tries to steal token from a specified process and execute a token assigned process. Most of methods require administrative privileges.
Currently, 4 methods are implemented:
• To execute a token assigned process with CreateProcessAsUser API, set -m option to 0;
• When set -m option to 1, this tool tries to create a suspended process and update the primary token to a stolen token. This method cannot be used for changing Session ID due to kernel restriction;
• If set -m option is set to 2, creates a new token assigned process with Secondary Logon Service;
• If set -m option is set to 3, creates a new token assigned process with PPID spoofing method.
👍3🔥3
Forwarded from Stuff for Geeks (Qho Knowa)
Fascinating C code: TCP sockets & HTTP file downloads using only ntdll exports (NtCreateFile & NtDeviceIoControlFile syscalls). Bypasses Winsock for low-level Windows networking.
https://www.x86matthew.com/view_post?id=ntsockets
#Windows
#Programming
https://www.x86matthew.com/view_post?id=ntsockets
#Windows
#Programming
❤3👍2🔥2
Forwarded from Go Casts 🚀
یادگیری زبان Rust احتمالا یکی از کارایی هست که خیلی هامون دوست داریم انجام بدیم. بعضی ها هم ممکنه انجامش داده باشن و لذت ش رو برده باشن.
سایت corrode.dev مقاله های جذابی منتشر میکنه در مورد Rust
این مقاله یه لیست جذاب داره از منابعی که شما میتونید برای یادگیری Rust ازش استفاده کنید.
در مورد یادگیری زبان جدید هم یه تجربه خوب شاید این باشه که سعی کنید گاه و بیگاه در مورد زبان مورد نظرتون مطالعه پراکنده داشته باشید، این مطالعه درک شما رو نسبت به مفاهیم و جذابیت های زبان بیشتر میکنه و به شما شوق بیشتری میده که یادش بگیرید.
Learning Material for Idiomatic Rust
https://corrode.dev/blog/idiomatic-rust-resources/
@gocasts
#rust
سایت corrode.dev مقاله های جذابی منتشر میکنه در مورد Rust
این مقاله یه لیست جذاب داره از منابعی که شما میتونید برای یادگیری Rust ازش استفاده کنید.
در مورد یادگیری زبان جدید هم یه تجربه خوب شاید این باشه که سعی کنید گاه و بیگاه در مورد زبان مورد نظرتون مطالعه پراکنده داشته باشید، این مطالعه درک شما رو نسبت به مفاهیم و جذابیت های زبان بیشتر میکنه و به شما شوق بیشتری میده که یادش بگیرید.
Learning Material for Idiomatic Rust
https://corrode.dev/blog/idiomatic-rust-resources/
@gocasts
#rust
👍8❤2👎1
Windows Registry Forensics Learning Path ( 2022 )
https://www.infosecinstitute.com/skills/learning-paths/windows-registry-forensics/
following file just include videos & pdf ( thanks " ᏗᏰᏂᎥᏝᏗᏕᏂ ֆɨռɢɦ 🇮🇳 " for sharing the file )
https://www.infosecinstitute.com/skills/learning-paths/windows-registry-forensics/
following file just include videos & pdf ( thanks " ᏗᏰᏂᎥᏝᏗᏕᏂ ֆɨռɢɦ 🇮🇳 " for sharing the file )
👍1
Windows Kernel Resources: Development, Exploitation, and Analysis
credit :Tetsuo
A collection of resources for Windows kernel development, exploitation, analysis, and security. Suitable for beginners to experts, this compilation covers a wide range of topics including driver development, reverse engineering, vulnerability research, and Windows internals.
https://x.com/7etsuo/status/1816285806547591371
#twitter_article
will post this article here very nice collection , enough for 3 years of studing😂😭
credit :Tetsuo
A collection of resources for Windows kernel development, exploitation, analysis, and security. Suitable for beginners to experts, this compilation covers a wide range of topics including driver development, reverse engineering, vulnerability research, and Windows internals.
https://x.com/7etsuo/status/1816285806547591371
#twitter_article
❤6👍4😁1
The Security Principle Every Attacker Needs to Follow
Credit : Elad Shamir
https://posts.specterops.io/the-security-principle-every-attacker-needs-to-follow-905cc94ddfc6
Credit : Elad Shamir
I decided to focus on “Identity-Driven Offensive Tradecraft”, in this post, I will explain what I mean by that and why it is so central to attack paths and red team operations.
https://posts.specterops.io/the-security-principle-every-attacker-needs-to-follow-905cc94ddfc6
👍5
THREAD NAME-CALLING – USING THREAD NAME FOR OFFENSE
https://research.checkpoint.com/2024/thread-name-calling-using-thread-name-for-offense/
[ GitHub ]
Also check:
1- Atom Bombing technique 2016
2- Pool Party 2023
3-“Windows Process Injection in 2019” by Amit Klein and Itzik Kotler
https://research.checkpoint.com/2024/thread-name-calling-using-thread-name-for-offense/
[ GitHub ]
Also check:
1- Atom Bombing technique 2016
2- Pool Party 2023
3-“Windows Process Injection in 2019” by Amit Klein and Itzik Kotler
👍4🔥4