⚠️ در نتیجه، اگر قابلیت Reverse Proxy Authentication فعال باشد، هر مهاجمی که به پورت HTTP کانتینر دسترسی داشته باشد میتونه با جعل هدر "X-WEBAUTH-USER"، خودش رو به‌ جای هر کاربر (حتی ادمین) معرفی بکنه و احراز هویت را دور بزنه.

نکته مهم اینکه فقط Docker Image های رسمی تا نسخه 1.26.2 را تحت تأثیر قرار میدهد و نسخه‌ های Binary یا نصب‌هایی که از تنظیمات پیش‌فرض "app.example.ini" استفاده میکنند، آسیب‌پذیر نیستند.
Dork :
FOFA Query: app="Gitea"

برای دریافت به‌روزرسانی‌های امنیتی روزانه، و اخبار امنیت سایبری مارو به عنوان منبع مورد نظر خود دنبال کنید ->❤️💻
GROUP ™️
@mandegar_sec | channel

Server Side Template Injection (SSTI) in AI Prompt Templates
Python-based Web Application Attacks👾

با رشد استفاده از فریم‌ ورک‌هایی مثل LangChain و Template های داینامیک برای ساخت اپلیکیشن‌های AI، یک سطح حمله جدید هم به وجود آمده

این مقاله از PyFu به بررسی Server-Side Template Injection (SSTI) در سیستم‌های مبتنی بر هوش مصنوعی میپردازد؛ جایی که ترکیب اشتباه ورودی کاربر با Prompt Template میتونه از یک مشکل ساده به یک آسیب‌پذیری جدی تبدیل شود.

📌 نکته مهمی که وجود داره SSTI با Prompt Injection یکی نیست.

در Prompt Injection، مهاجم تلاش میکنه رفتار مدل رو با دستورهای متنی تغییر بده؛ اما در SSTI، مشکل در نحوه پردازش Templateها توسط برنامس و در بعضی شرایط میتونه حتی به اجرای کد روی سرور (RCE) منجر بشه.

مقاله توضیح میده که چجور استفاده ناامن از Template Engineهایی مثل Jinja2 میتونه باعث بشه مهاجم به بخش‌هایی از محیط اجرای Python دسترسی پیدا کند و اطلاعات حساسی مثل Credential ها یا داده‌های داخلی را هدف قرار دهد.

🔍 موضوعات اصلی مقاله:
• تفاوت SSTI و Prompt Injection
• ریسک استفاده ناامن از Prompt Templateها
• نحوه شکل‌گیری این آسیب‌پذیری در Pipelineهای AI
• اهمیت جداسازی داده کاربر از ساختار Template
• استفاده از محیط‌های محدود و ایزوله برای کاهش ریسک

با توجه به اینکه اپلیکیشن‌های AI روزبه‌روز بیشتر وارد محیط‌های واقعی میشوند، بررسی این نوع آسیب‌پذیری‌ها برای هر کسی که در حوزه AI Security، Web Security و Bug Bounty فعالیت میکند، اهمیت زیادی دارد.

🔗 مطالعه کامل:
https://pyfu.io/python-based-web-application-attacks/injection-attacks/server-side-template-injection-ssti-in-ai-prompt-templates

برای دریافت به‌روزرسانی‌های امنیتی روزانه، و اخبار امنیت سایبری مارو به عنوان منبع مورد نظر خود دنبال کنید ->❤️💻
GROUP ™️
@mandegar_sec | channel

#AISecurity #SSTI #LangChain #WebSecurity #BugBounty

پارت دو رو قرار بدیم؟

https://youtu.be/K-mMLETBE0g

آسیب‌پذیری CVE-2026-20896 در Gitea؛ جعل هویت هر کاربر با یک هدر HTTP؟
در این ویدیو به بررسی CVE-2026-20896 در Gitea می‌پردازیم؛ یک آسیب‌پذیری مرتبط با پیکربندی احراز هویت از طریق Reverse Proxy در نسخه‌های آسیب‌پذیر Docker Image.

در این سناریو، تنظیمات نادرست مربوط به Trusted Proxies باعث می‌شود درخواست‌هایی که مستقیماً از سمت کلاینت ارسال می‌شوند، به‌عنوان درخواست‌های معتبر از طرف Reverse Proxy در نظر گرفته شوند.

لینک poc من :
https://github.com/XaocZenon/CVE-2026-20896

⚠️ Security Warning:
All testing in this video is only performed in an isolated lab environment and on systems that we own or have explicit permission to test. Any use of this information against unlicensed systems

#CVE #Gitea #CyberSecurity #Docker #Vulnerability #CyberSecurityLab

41. Only keys, without values:

{
"login":,
"password":
}

42. Insertion of control characters:

{
"login": "ad\u0000min",
"password": "pass\u0000word"
}

43. Long Unicode Strings:

{
"login": "\u0061"*10000,
"password": "\u0061"*10000
}

44. Newline Characters in Strings:

{
"login": "ad\nmin",
"password": "pa\nssword"
}

45. Tab Characters in Strings:

{
"login": "ad\tmin",
"password": "pa\tssword"
}

46. Test with HTML content in Strings:

{
"login": "<b>admin",
"password": "password"
}

47. JSON Injection in Strings:

{
"login": "{\"injection\":\"value\"}",
"password": "password"
}

48. Test with XML content in Strings:

{
"login": "admin",
"password": "password"
}

49. Combination of Number, Strings, and Special characters:

{
"login": "ad123min!@",
"password": "pa55w0rd!@"
}

50. Use of environment variables:

{
"login": "${USER}",
"password": "${PASS}"
}

51. Backslashes in Strings:

{
"login": "ad\\min",
"password": "pa\\ssword"
}

52. Long strings of special characters:

{
"login": "!@#$%^&*()"*1000,
"password": "!@#$%^&*()"*1000
}

53. Empty Key in JSON:

{
"": "admin",
"password": "password"
}

55. JSON Injection in Key:

{
"{\"injection\":\"value\"}
": "admin",
"password": "password"
}

56. Quotation marks in strings:

{
"login": "\"admin\"",
"password": "\"password\""
}

57. Credentials as nested arrays:

{
"login": [["admin"]],
"password": [["password"]]
}

58. Credentials as nested objects:

{
"login": {"username": {"value": "admin",
"password": {"password": {"value":
"password"
}

59. Keys as numbers:

{
123: "admin",
456: "password"
}

60. Testing with greater than and less than signs:

{
"login": "admin>1",
"password": "<password"
}

61. Testing with parentheses in credentials:

{
"login": "(admin)",
"password": "(password)"
}

62. Credentials containing slashes:

{
"login": "admin/user",
"password": "pass/word"
}

63. Credentials containing multiple data types:

{
"login": ["admin",
123,
true,
null,
{"username": ["admin"],
"password": ["password",
123,
false,
null,
{"password": "password"]}}
}

64. Using escape sequences:

{
"login": "admin\\r\\n\\t",
"password": "password\\r\\n\\t"
}

65. Using curly braces in strings:

{
"login": "{admin}",
"password": "{password}"
}

66. Using square brackets in strings:

{
"login": "[admin]",
"password": "[password]"
}

68. Strings with only special characters:

{
"login": "!@#$$%^&*()",
"password": "!@#$$%^&*()"
}

69. Strings with control characters:

{
"login": "admin\b\f\n\r\t\v\0",
"password": "password\b\f\n\r\t\v\0"
}

71. Null characters in strings:

{
"login": "admin\0",
"password": "password\0"
}

72. Exponential numbers as strings:

{
"login": "1e5",
"password": "1e10"
}

73. Hexadecimal numbers as strings:

{
"login": "0xabc",
"password": "0x123"
}

74. Leading zeros in numeric strings:

{
"login": "000123",
"password": "000456"
}

75. Multilingual input (here, English and Korean):

{
"login": "admin관리ìž",
"password": "password비밀번호"
}

76. Extremely long keys:

{
"a"*10000: "admin",
"b"*10000: "password"
}

78. Extremely long unicode strings:

{
"login": "\u0061"*10000,
"password": "\u0062"*10000
}

79. JSON strings with semicolon:

{
"login": "admin;",
"password": "password;"
}

80. JSON strings with backticks:

{
"login": "`admin`",
"password": "`password`"
}

81. JSON strings with plus sign:

{
"login": "admin+",
"password": "password+"
}

82. JSON strings with equal sign:

{
"login": "admin=",
"password": "password="
}

83. Strings with Asterisk (*) Symbol:

{
"login": "admin*",
"password": "password*"
}

برای دریافت به‌روزرسانی‌های امنیتی روزانه، و اخبار امنیت سایبری مارو به عنوان منبع مورد نظر خود دنبال کنید ->❤️💻
GROUP ™️
@mandegar_sec | channel

توی این ویدیو سعی کردم به صورت ساده و با یه CTF ساده بهتون بگم چجوری از AI برای بحث پنتست / باگ بانتی / رد تیم و ... استفاده کنیم.

(سعی کنین خودتون تست کنین تا دستتون بیاد کامل)

https://youtu.be/Tedkf30g00E

همین الان این ریلز رو ببین! 🚀

یه آسیب‌پذیری بحرانی جدید در وردپرس کشف شده که یه فرصت طلایی برای شکارچی‌های باگ (Bug Hunters) ایجاد کرده. اگه دست بجنبونی و از متدولوژی و ابزارهایی که توی این ویدیو و دایرکت توضیح دادم استفاده کنی، شانس بالایی برای گرفتن بانتی‌های سنگین داری.
بانتی ها این ریلز به دلیل اینکه ایمپکت کرتیکال هست از ۲-۳ هزاردلار به بالا هست پس زمان به شدت مهمه
تایم‌لاین این آسیب‌پذیری به شدت حساسه؛ پس معطل نکن!


https://www.instagram.com/reel/Da-1BvGNcc9/?igsh=YjE1cnRicGp4bDg5

موقع تست SSRF فقط روی "169.254.169.254" تمرکز نکنید

خیلی وقت‌ ها مشکل اصلی، اختلاف بین Parser ها و Resolver هاس، نه خود Payload.

برای همین این موارد رو هم به Wordlist اضافه کنید :

http://127.1/
http://0/
http://[::ffff:127.0.0.1]/
http://user@internal.host/
http://allowed.com@127.0.0.1/
Decimal / Octal IP
Redirect → Internal Target

📌Tips :
حتماً سناریوی Redirect رو هم تست کنید بعضی برنامه‌ ها فقط URL اولیه رو اعتبارسنجی میکنن، اما بعد از Redirect، درخواست بدون محدودیت به مقصد داخلی ارسال میشه.

برای دریافت به‌روزرسانی‌های امنیتی روزانه، و اخبار امنیت سایبری مارو به عنوان منبع مورد نظر خود دنبال کنید ->❤️💻
GROUP ™️
@mandegar_sec | channel

#BugBounty #SSRF #WebSecurity #Recon

84. JSON containing JavaScript code:

{
"login": "admin<script>alert('hi')</script>",
"password": "password"
}

85. Negative numbers as strings:

{
"login": "-123",
"password": "-456"
}

86. Values as URLs:

{
"login": "https://admin.com",
"password": "https://password.com"
}

87. Strings with email format:

{
"login": "admin@admin.com",
"password": "password@password.com"
}

88. Strings with IP address format:

{
"login": "192.0.2.0",
"password": "203.0.113.0"
}

89. Strings with date format:

{
"login": "2023-08-03",
"password": "2023-08-04"
}

90. JSON with exponential values:

{
"login": 1e+30,
"password": 1e+30
}

91. JSON with negative exponential values:

{
"login": -1e+30,
"password": -1e+30
}

92. Using Zero Width Space (U+200B) in strings:

{
"login": "admin​",
"password": "password​"
}

93. Using Zero Width Joiner (U+200D) in strings:

{
"login": "adminâ€",
"password": "passwordâ€"
}

94. JSON with extremely large numbers:

{
"login": 12345678901234567890,
"password": 12345678901234567890
}

95. Strings with backspace characters:

{
"login": "admin\b",
"password": "password\b"
}

96. Test with emoji in strings:

{
"login": "admin😀",
"password": "password😀"
}

97. JSON with comments, although they are not officially supported in JSON:

{
/*"login": "admin",
"password": "password"*/
}

98. JSON with base64 encoded values:

{
"login": "YWRtaW4=",
"password": "cGFzc3dvcmQ="
}

99. Including null byte character (may cause truncation):

{
"login": "admin\0",
"password": "password\0"
}

100. JSON with credentials in scientific notation:

{
"login": 1e100,
"password": 1e100
}

102. Strings with octal values:

{
"login": "\141\144\155\151\156",
"password":"\160\141\163\163\167\157\162\144"
}

103.

{
root:{
"username": "admin",
"password":"admin"
}
}

104.

basic => usernam-dmin
username[]=ad
username[0]=a
username=admin&user name-auin
delete username=admin

برای دریافت به‌روزرسانی‌های امنیتی روزانه، و اخبار امنیت سایبری مارو به عنوان منبع مورد نظر خود دنبال کنید ->❤️💻
GROUP ™️
@mandegar_sec | channel

سلام دوستان
تو این پست رفتیم سراغ تحلیل و بررسی عملی یکی از آسیب‌پذیری‌های جدید و خیلی جذاب تو اکتیو دایرکتوری و سرویس‌های گواهی مایکروسافت (AD CS) یعنی CVE-2026-54121 که معروف شده به Certi-Ghost.
داستان از این قراره که وقتی سرور CA نتونه اطلاعات یک هویت رو به‌طور مستقیم به دست بیاره، یک مکانیزم پشتیبان به نام Chase فعال میشه. در این پست بررسی کردیم که چطور یک مهاجم با دستکاری دو مشخصهٔ CDC و RMD می‌تونه سرور CA رو فریب بده، گواهیِ هویت Domain Controller را دریافت کرده و در نهایت با تکنیک DCSync کنترل کل دامین رو به دست بگیره.

یکی از جذاب ترین تکنیک هایی هستش که میتونید تو سناریو های شبیه سازی ردتیم یا پنتست ازش استفاده کنید .
امیدوارم که از این پست لذت ببرید .

#Red_Team #AD #Pentest #Network #CA
➖➖➖➖➖
CHANNEL

Leaks from hacker forums https://github.com/FSECDEV/LEAKSFORUMS

Channel | Group

برای دومین بار بنا به درخواست فراوانی که در این چهار سال داشتیم که کارگاه هایی برگزار شود که به صورت تخصصی فقط به یک بخش خاص اشاره شود و کوتاه باشد
و دومین کارگاه با یکی دیگر از اسیب پذیری مورد علاقه خودم شروع خواهد شد :
Broken access control
بی راه نیست اگه بگم 35 درصد کل بانتی دو سال اخیر من با این تایپ حمله بوده

9 مهر:‌ درک این اسیب پذیری به همراه حل مثال ها فراوان
16 مهر:‌ بررسی عمیق این اسیب پذیری از دید تجربه و مثال ها متنوعد
23 مهر:‌ ترکیب اسیب پذیری ها کم ارزش با این اسیب پذیری برای تبدیل گزارش های مختلف به گزارش های کرتیکال
30 مهر:‌ لایو هکینگ و هانتینگ


نکته: تقریبا با این تایپ حمله بسیاری از xss های من تبدیل به کرتیکال شد!




برای ثبت نام میتوانید از لینک زیر استفاده کنید:


https://www.instagram.com/s/aGlnaGxpZ2h0OjE3OTAxODAzNzE4NTg5MDI3?story_media_id=3979547667200320168&stkn=MW15czFmNXd1NmhtMA==

دقت کنید ببینید آقا بهروز چی میگه:
https://www.youtube.com/watch?v=wKodzXgXbWg
کسانی که توی باگ بانتی هستند
خلاصش با AI :
🤖 ۱۲ سال کارنامه یکی از هکرهای بزرگ!
تصور کنید تمام کارهایی که در ۱۲ سال گذشته انجام داده‌اید را به یک هوش مصنوعی بدهید و بگویید: "بدون هیچ تعارفی، نقاط ضعفم را بکوب توی صورتم!"
این دقیقاً کاری است که NahamSec (یکی از برترین هکرهای HackerOne) انجام داد. او تمام ۱۵۰۰ گزارش باگ‌بانتی خود روی ۲۲۸ برنامه مختلف (از سال ۲۰۱۴ تا نوامبر ۲۰۲۵) را به هوش مصنوعی (Claude) داد تا بدون سوگیری عملکردش را تحلیل کند.
نتیجه این تحلیل، حقایق و آمارهایی بود که خود NahamSec را هم شوکه کرد. در ادامه، چکیده این تحلیل بی‌رحمانه را می‌خوانیم:
🔴 ۱. قبرستان گزارش‌ها (یک‌سوم زحمات بر باد رفته!) هوش مصنوعی به او نشان داد که از این ۱۵۰۰ گزارش، ۵۶۱ مورد (یعنی بیش از یک‌سوم) مطلقاً به هیچ‌جا نرسیده‌اند! یا تکراری (Duplicate) بوده‌اند، یا N/A و یا صرفاً Informative. یعنی حتی بزرگترین هکرها هم پر از گزارش‌های بی‌فایده‌اند.
📉 ۲. توهم کمیت؛ ۱۷۳ شلیک با تفنگ خالی!
سال ۲۰۱۴ (سال اول): او ۱۷۳ گزارش فرستاد، اما فقط ۱۶٪ آن‌ها تایید شدند (۱ از هر ۶ گزارش). او فکر می‌کرد راز موفقیت در ارسالِ انبوه است.
سال ۲۰۱۹: او فقط ۱۱۲ گزارش فرستاد، اما ۷۵٪ آن‌ها تایید شدند و پول بسیار بیشتری ساخت. درس؟ او باگ‌های سخت‌تری یاد نگرفته بود، بلکه فقط "فیلتر کردن" را یاد گرفته بود و هر خزعبلاتی را سابمیت نمی‌کرد!
🤯 ۳. باگ‌های خسته‌کننده اما پول‌ساز > باگ‌های رویایی! وقتی هوش مصنوعی باگ‌ها را بر اساس "نرخ تایید (Signal Rate)" مرتب کرد، نتیجه عجیب بود:
باگ رویایی RCE (اجرای کد از راه دور): فقط ۶۲٪ مواقع تایید می‌شد.
باگ ساده Subdomain Takeover: با قدرت ۹۰٪ مواقع تایید می‌شد!
چرا؟ چون سر باگ RCE، شرکت‌ها مدام بحث می‌کنند (مثلاً می‌گویند سرور Sandbox است یا Impact ندارد)، اما سر Takeover زیردامنه نمی‌توان بحث کرد؛ یا دامنه آسیب‌پذیر است یا نیست! باگ‌هایی بفرستید که نتوانند روی تاثیرش با شما بحث کنند.
🔥 اما راز اصلی موفقیت NahamSec چه بود؟
هوش مصنوعی متوجه یک الگوی تکرارشونده در گزارش‌های موفق او شد: استراتژی کمپین! NahamSec سال‌هاست که دنبال ۲۰ باگ مختلف روی یک تارگت نمی‌گردد. او یک ایده را روی ده‌ها تارگت پیاده می‌کند.
🎯 تکامل ۱۰ ساله یک پی‌لود ساده: او از یک آسیب‌پذیری پایه‌ای (مثل تزریق پی‌لود در فیلد Name) یک معدن طلا ساخت.
در سال ۲۰۱۵: در فیلد "نام خانوادگی" پی‌لود می‌زد و XSS می‌گرفت.
در سال ۲۰۲۳: همان پی‌لود را در فیلد "نام محصول" در فروشگاه‌ها می‌زد.
در سال ۲۰۲۵: همان کار را روی "نام کالا" کرد و از دستیار هوش مصنوعی Prompt Injection گرفت! یک ایده ثابت، با ۱۰۷ گزارش موفق در ۳۳ شرکت مختلف!
💡 حرف آخر: دوران پیدا کردن باگ‌های کلاسیک مثل CSRF و SQLi ساده در فرم‌ها به سر آمده (فریم‌ورک‌ها آن‌ها را کشته‌اند). هانتِ امروز، یعنی پیدا کردن یک رفتار عجیب در معماری یک سیستم، و اسکن کردن تمام اینترنت برای پیدا کردن همان یک رفتار!

Source Code Review Methodology

https://notes.asifnawazminhas.com/source-code-review/methodology/

برای دریافت به‌روزرسانی‌های امنیتی روزانه، و اخبار امنیت سایبری مارو به عنوان منبع مورد نظر خود دنبال کنید ->❤️💻
GROUP ™️
@mandegar_sec | channel

#BugBounty #CyberSecurity #Sourcecode #Review

🔴 تحریم‌ها این‌بار به HTTPS بانک‌های ایرانی رسیدند!
ماجرا چیه؟ 🤔
گزارش‌ها می‌گن بعضی از بانک‌های ایرانی به‌دلیل تحریم‌های آمریکا، در تأمین یا تمدید گواهی امنیتی SSL/TLS برای سایت‌های بانکی با مشکل مواجه شده‌اند و بعضی بانک‌ها مجبور به تغییر دامنه سایت خود شده‌اند.
حالا SSL/TLS چیه؟
همون قفلی 🔒 که کنار آدرس سایت می‌بینید و به مرورگر می‌گه:
«این سایت واقعاً همون سایتیه که ادعا می‌کنه و ارتباط شما باهاش رمزگذاری شده.»
نکته مهم اینه که OFAC خودش صادرکننده گواهی SSL نیست؛ اما تحریم‌ها می‌تونن باعث بشن شرکت‌های بین‌المللی ارائه‌دهنده این خدمات، به بانک‌های تحریم‌شده سرویس ندن یا همکاری‌شون رو محدود کنن.
یعنی تحریم فقط به پول و انتقال بانکی محدود نمی‌شه؛ حتی بعضی از زیرساخت‌های فنی مورد استفاده بانک‌ها برای ارائه خدمات اینترنتی هم می‌تونن تحت تأثیر قرار بگیرن.
📌 گزارش کامل:
Digiato Global — گزارش تغییر دامنه و گواهی SSL بانک‌های ایرانی

🔸نوتلا، کلاشنیکف و رویای عاشقانه؛ وقتی بلاگرها برای تروریسم یارگیری می‌کنند!

گروه‌های تندرو و شبکه‌های نفوذ خیلی خوب یاد گرفته‌اند که با حرف‌های خشک، مذهبی یا نشان دادن خشونت، نمی‌توانند جوان‌ها را جذب کنند. به همین خاطر سراغ یک ترفند مدرن رفته‌اند: «اینفلوئنسری و بلاگری لایف‌استایل». در این روش، آن‌ها به‌جای بیانیه‌های رسمی، صفحاتی درست می‌کنند که دقیقاً شبیه پیج‌های روزمره‌گی، آشپزی و مد است. هدفشان هم ساده است: مخفی کردن واقعیت‌های ترسناک پشت تصاویری از حس رفاقت، ماجراجویی و زندگی رمانتیک، تا گارد مخاطب کاملاً بشکند و جذب ماجرا شود.

🔹نمونه واقعی: جهادی‌های نوتلا!
بین سال‌های ۲۰۱۴ تا ۲۰۱۶ در شهر رقه سوریه، داعش از این روش به شکلی عجیب استفاده کرد. دختران جوانی مثل «اقصی محمود» (دانشجوی اسکاتلندی که فرار کرده بود) در تامبلر و توییتر مثل یک بلاگر فعال شدند؛ عکس‌هایی از شیشه‌های شکلات نوتلا، پنکیک‌های داغ، گربه‌های ناز در کنار اسلحه و زندگی عاشقانه‌شان با جنگجوها منتشر می‌کردند. این تصویرسازی شیک و فانتزی باعث شد بیش از ۶۰۰ دختر و زن جوان اروپایی و آمریکایی، از جمله سه دختر دبیرستانی مشهور از لندن، خانه، دانشگاه و خانواده‌شان را رها کنند و خودشان را به دل یکی از خطرناک‌ترین مناطق جنگی برسانند.
این ماجرا نشان داد یک عکس خوش‌رنگ‌ولعاب در شبکه‌های اجتماعی، گاهی می‌تواند از صدها گلوله و موشک تاثیرگذارتر و البته ویران‌کننده‌تر باشد.

😎 مدل GPT-6 ASTRA به صورت رایگان در MiniApps در دسترس است!

قدرتمندترین مدل شرکت OpenAI، بدون هیچ هزینه‌ای.

آنچه دریافت خواهید کرد:

✦ مدل GPT-6 Astra به صورت رایگان
✦ قابلیت‌های استدلال، کدنویسی و انجام وظایف پیچیده
✦ اجرا در مرورگر، بدون نیاز به نصب

نحوه شروع:

1. این لینک را باز کنید.
2. ثبت‌نام کنید.

خب سلام اومدیم یه مقدار درباره execve یه توضیح بدیم که احتمالا همتون وقتی یکم با strace کار میکنین این syscall میبینید . کارش بخوام خیلی کوتاه بگم اینه که میاد یه image پروسه فعلی رو با یه برنامه جدید جایگزین میکنه . شاید بگی عین fork هست ولی نه توی این عمل process جدید درست نمیشه بلکه همونه ولی فقط اون برنامه ای که درحال اجرا بود جایگزین میشه و یه برنامه جدید اجرا میشه .
سینتکسش هم به صورت زیره:

int execve(
    const char *pathname,
    char *const argv[],
    char *const envp[]
);

pathname خب مربوط به مسیر اون فایل اجرایی هست که میخوایم توی پراسس فعلی اجرا بشه /bin/ls
argv هم مربوط به آرگومان هایی هست که اون فایل اجرایی ما میگیره مثلا ss -t
envp هم مربوط به اون متغیر های Environment هستش.

بخوایم الان با توجه به توضیحایی که بالا دادیم این بخشا رو پر کنیم به صورت زیر در میاد
execve("/bin/ls", args, env);

حالا برای مثال اگه بخوایم ls -la بگیریم متغیر args باید به صورت زیر پر کنیم :

char *args[] = {
    "ls",
    "-l",
    "/home",
    NULL
};

اینم یادتون باشه آخر آرایه هم باید با NULL پر بشه که سیستم بفهمه آرگومان ها کجا به اتمام میرسند .
در واقع اینطوریه :
./main_program:

#include <stdio.h>
#include <unistd.h>

int main()
{
    char *args[] = {
        "program2",
        "hello",
        "world",
        NULL
    };
    printf("Before execve\n");
    execve("./program2", args, NULL);
    printf("After execve\n");
    return 0;
}

./program2:

#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("I am program2\n");
    printf("argc = %d\n", argc);
    for (int i = 0; i < argc; i++)
    {
        printf("argv[%d] = %s\n", i, argv[i]);
    }
    return 0;
}

خب توی این بخش میاد آرگومان های داده شده توی برنامه اول رو در برنامه دوم به نمایش میزاره و میشه گفت تمام کاری که میکنه همینه .یه نکته دیگه هم اینه که pid این برنامه اگه 100 بار این وسط برنامه جدید با execve بیاد وسط عوض نمیشه و جدا از اون وقتی یه برنامه جدید با execve اجرا میشه ادامه کدی که توی برنامه اول داریم اجرا نمیشه مگر اینکه به خطا بخوریم توی اجرا کردن برنامه دوم .
و در آخر، کنار execve چندین تابع کتابخانه‌ای هم وجود داره که همگی wrapper هستن و execve رو صدا می‌زنن execl، execlp، execle، execv و execvp که خب یه سری تفاوت دارن و زیاد توشون دیپ نمیشیم .
➖➖➖➖➖
CHANNEL