روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ چند روز پیش توضیح دادیم که تیم GReAT کسپرسکی در سی و هفتمین کنگره‌ی ارتباطات آشوب در هامبورگ پیرامون مبحث «حمله تریانگولاسیون: حمله به آیفون محققین چگونه اتفاق می‌افتد؟» سخنرانی کرد. در این مقاله قرار است به تفصیل گفته‌های آن‌ها را شرح دهیم. با ما همراه باشید.

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

زنجیره حمله Operation Triangulation

در اینجا خلاصه‌ای سریع از حمله صفر کلیک iMessage است که از چهار آسیب‌پذیری روز صفر استفاده می‌کرد و برای کار بر روی نسخه‌های iOS تا iOS 16.2 طراحی شده بود آورده‌ایم:

•         مهاجمین یک لینک مخرب iMessage را ارسال می‌کنند که برنامه بدون نشان دادن هیچ نشانه‌ای به کاربر، آن را پردازش می‌کند.
•         این لینک از آسیب‌پذیری اجرای کد از راه دور CVE-2023-41990 در دستورالعمل فونت ADJUST TrueType غیرمستند و فقط برای اپل استفاده می‌کند. این دستورالعمل از اوایل دهه نود قبل از حذف آن توسط یک پچ وجود داشت.
•         از برنامه نویسی بازگشت/پرش و چندین مرحله نوشته شده در زبان پرس و جو NSExpression/NSPredicate استفاده و محیط آرشیو JavaScriptCore را اصلاح می‌کند تا یک اکسپلویت افزایش امتیاز نوشته شده در جاوا اسکریپت را اجرا نماید.
•         این اکسپلویت جاوا اسکریپت مبهم شده است تا کاملاً ناخوانا شود و اندازه آن به حداقل برسد. با این حال، حدود 11000 خط کد دارد که عمدتاً به جاوا اسکریپت کور و تجزیه و دستکاری حافظه هسته اختصاص داده شده.
•         از ویژگی اشکال زدایی JavaScriptCore DollarVM برای به دست آوردن توانایی دستکاری حافظه JavaScriptCore از اسکریپت و اجرای توابع API بومی سوء استفاده می‌کند.
•         این برای پشتیبانی از آیفون های قدیمی و جدید طراحی شده و شامل یک کد تأیید هویت اشاره گر pac   برای اکسپلویت مدل‌های اخیر می‌شود.
•         از آسیب‌پذیری سرریز اعداد صحیح CVE-2023-32434 در سیستم‌های نگاشت حافظه XNU  برای دسترسی خواندن/نوشتن به کل حافظه فیزیکی دستگاه در سطح کاربر استفاده می‌کند.
•         از رجیسترهای ورودی/خروجی (MMIO) با حافظه سخت افزاری برای دور زدن لایه حفاظتی صفحه PPL)  ) استفاده می‌کند. این به عنوان CVE-2023-38606 کاهش یافت.
•         پس از اکسپلویت تمام آسیب‌پذیری‌ها، اکسپلویت جاوا اسکریپت می‌تواند هر کاری که می‌خواهد با دستگاه انجام دهد، از جمله نرم‌افزارهای جاسوسی، اما مهاجمین تصمیم گرفتند: (الف) فرآیند IMAgent را راه‌اندازی و باری را تزریق کنند که مصنوعات اکسپلویت از دستگاه پاک شوند. (ب) یک فرآیند سافاری را در حالت نامرئی اجرا و در مرحله بعدی آن را به یک صفحه وب ارسال کنند.
•         صفحه وب دارای یک اسکریپت هستند که قربانی را تأیید و در صورت عبور از چک ها، مرحله بعدی را دریافت می‌کنند: اکسپلویت سافاری.
•         اکسپلویت سافاری از CVE-2023-32435 برای اجرای یک کد پوسته استفاده می‌کند.
•         Shellcode یک اکسپلویت هسته دیگر را در قالب یک فایل شی Mach و از همان آسیب‌پذیری ها استفاده می کند: CVE-2023-32434 و CVE-2023-38606.همچنین از نظر مقیاس و عملکرد بسیار بزرگ است، اما کاملاً با اکسپلویت هسته نوشته شده در جاوا اسکریپت تفاوت دارد. بخش‌های خاصی مربوط به اکسپلویت آسیب‌پذیری‌های فوق‌الذکر، همه آن دو است. با این حال، بیشتر کد آن نیز به تجزیه و دستکاری حافظه هسته اختصاص دارد. این شامل ابزارهای مختلف پس از بهره‌برداری است که عمدتاً بدون استفاده هستند.
•         این اکسپلویت امتیازات ریشه را به دست آورده و مراحل دیگر را اجرا می‌کند که نرم افزارهای جاسوسی بارگیری می شوند. در پست های قبلی به این مراحل پرداختیم.
•         کسپرسکی تقریباً مهندسی معکوس همه جنبه‌های این زنجیره حمله را تمام کرده و در سال 2024 مجموعه‌ای از مقالات را منتشر خواهیم کرد که جزئیات هر آسیب‌پذیری و نحوه بهره‌برداری از آن را شرح می‌دهد.

با این وجود، ابعاد یک آسیب‌پذیری خاص وجود دارد که هنوز نتوانسته‌ایم کامل آن را درک کنیم:

معمای آسیب‌پذیری CVE-2023-38606

آنچه می‌خواهیم در مورد آن بحث کنیم مربوط به آسیب‌پذیری است که به عنوان CVE-2023-38606 محدود شده. مدل های اخیر آیفون دارای محافظت امنیتی مبتنی بر سخت افزار اضافی برای مناطق حساس حافظه هسته هستند. این محافظت مانع از آن می‌شود که مهاجمین در صورت خواندن و نوشتن حافظه هسته، کنترل کامل دستگاه را به دست آورند، همانطور که در این حمله با بهره‌برداری از CVE-2023-32434 به دست آمد. ما متوجه شدیم که برای دور زدن این حفاظت امنیتی مبتنی بر سخت افزار، مهاجمین از یکی دیگر از ویژگی های سخت افزاری SoC های طراحی شده توسط اپل استفاده کردند. اگر بخواهیم این ویژگی و نحوه استفاده مهاجمین از آن را توصیف کنیم، اینطور نتیجه‌گیری می‌شود که: آنها می توانند داده‌ها را در یک آدرس فیزیکی خاص بنویسند در حالیکه با نوشتن داده ها، آدرس مقصد، حفاظت حافظه مبتنی بر سخت افزار را دور می‌زنند. و هش داده ها به رجیسترهای سخت افزاری ناشناخته تراشه که توسط سیستم عامل استفاده نشده است.

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

ما در حال انتشار جزئیات فنی هستیم تا سایر محققین امنیتی iOS بتوانند یافته‌های ما را تایید کنند و توضیحات احتمالی در مورد نحوه اطلاع مهاجمان از این ویژگی سخت افزاری ارائه دهند.

جزئیات فنی

دستگاه‌های جانبی مختلف موجود در SoC ممکن است رجیسترهای سخت‌افزاری خاصی را ارائه دهند که می‌تواند توسط CPU برای کار با این دستگاه‌ها استفاده شود. برای این کار، این رجیسترهای سخت‌افزاری به حافظه قابل دسترسی CPU نگاشت و به عنوان "I/O با حافظهMMIO)  ) شناخته می‌شوند.

محدوده آدرس برای MMIO دستگاه‌های جانبی در محصولات اپل (iPhone، Mac، و دیگران) در قالب فایل ویژه ذخیره می شود: DeviceTree.فایل‌های درخت دستگاه را می‌توان از میان‌افزار استخراج و با کمک ابزار dt، محتوای آن‌ها را مشاهده کرد.

هنگام تجزیه و تحلیل سوء استفاده مورد استفاده در حمله Operation Triangulation، متوجه شدم که اکثر MMIOهایی که توسط مهاجمین برای دور زدن حفاظت حافظه هسته مبتنی بر سخت افزار استفاده می‌شود، به هیچ محدوده MMIO تعریف شده در درختچه‌ی دستگاه تعلق ندارند. این اکسپلویت، SoCهای اپل A12–A16 Bionic را هدف قرار می‌دهد و بلوک‌های ناشناخته MMIO را که در آدرس‌های زیر قرار دارند، هدف قرار می‌دهد: 0x206040000، 0x206140000 و 0x206150000.

این‌ها ما را بر آن داشت تا درختچه‌ی دستگاه‌های مختلف را برای دستگاه‌های مختلف و فایل‌های میان‌افزار مختلف بررسی کنیم: شانسی نبود. ما کد منبع در دسترس عموم را بررسی کردیم: شانسی نبود. ما تصاویر هسته، پسوندهای هسته، iboot و سیستم عامل کمک پردازنده را در جستجوی یک مرجع مستقیم به این آدرس ها بررسی کردیم: باز هم هیچ چیز. چگونه ممکن است که این اکسپلویت از MMIOهایی استفاده کند که توسط سیستم عامل استفاده نشده باشد؟ مهاجمین چگونه از آنها مطلع شدند؟ این آدرس‌های MMIO متعلق به کدام دستگاه(های) جانبی هستند؟ به ذهنمان رسید که باید بررسی کنیم چه MMIOهای شناخته شده دیگری در منطقه نزدیک به این بلوک های ناشناخته MMIO قرار دارند. آن رویکرد موفقیت آمیز بود.

بیایید نگاهی به ورودی درخت دستگاه برای gfx-asc، که همپردازگر GPU است، بیندازیم.

دارای دو محدوده MMIO است: 0x206400000–0x20646C000 و 0x206050000–0x206050008.  اجازه دهید نگاهی به ارتباط آنها با مناطق مورد استفاده توسط اکسپلویت بیندازیم.

برای دقیق تر بودن، این اکسپلویت از آدرس های ناشناخته زیر استفاده می‌کند: 0x206040000، 0x206140008، 0x206140108، 0x206150020، 0x206150040، و 0x206150048. . می‌بینیم که بیشتر آنها در ناحیه بین دو ناحیه gfx-asc و بقیه نزدیک به ابتدای اولین منطقه gfx-asc قرار دارند. این نشان می‌دهد که همه این رجیسترهای MMIO به احتمال زیاد متعلق به پردازنده گرافیکی هستند! پس از آن، نگاه دقیق‌تری به این اکسپلویت انداختیم و یک چیز دیگر را یافتیم که نظریه‌مان را تأیید کرد. اولین کاری که اکسپلویت در حین مقداردهی اولیه انجام می‌دهد، نوشتن در یک ثبات MMIO دیگر است که در یک آدرس متفاوت برای هر SoC قرار دارد.

با کمک درختچه‌ی دستگاه و ابزار Siguza، pmgr، توانستیم کشف کنیم که همه این آدرس‌ها با ثبات GFX در محدوده مدیریت قدرت MMIO مطابقت دارند. سرانجام، زمانی که تصمیم گرفتیم به ثبت‌های واقع در این مناطق ناشناخته دسترسی داشته باشیم، تأیید سوم را دریافت کردیم. تقریباً فوراً، همپردازگر GPU با پیامی مبنی بر "GFX SERROR Exception class=0x2f (SError interrupt)، IL=1، iss=0 – power(1)"  پدیدار شد.

به این ترتیب،  توانستیم تأیید کنیم که همه این رجیسترهای ناشناخته MMIO که برای بهره‌برداری استفاده می‌شوند، متعلق به پردازنده گرافیکی هستند. این به ما انگیزه داد تا نگاه عمیق‌تری به سیستم عامل آن بیندازم که در ARM نیز نوشته شده و رمزگذاری نشده، اما نتوانستیم چیزی مرتبط با این رجیسترها را در آنجا پیدا کنیم. تصمیم گرفتیم نگاه دقیق‌تری به نحوه عملکرد این رجیسترهای ناشناخته MMIO توسط این اکسپلویت بیندازیم.

ثبات 0x206040000 از سایر رجیسترها متمایز است زیرا در یک بلوک MMIO مجزا از سایر رجیسترها قرار دارد. فقط در مراحل اولیه‌سازی و نهایی سازی اکسپلویت لمس می‌شود: این اولین ثباتی است که در حین مقداردهی اولیه و آخرین ثبت در هنگام نهایی سازی تنظیم می‌شود. به تجربه ماt واضح بود که رجیستر یا ویژگی سخت افزاری مورد استفاده توسط اکسپلویت را فعال/غیرفعال  یا وقفه‌های کنترل شده را کنترل می‌کند. من شروع به دنبال کردن مسیر وقفه کردیم و خیلی زود توانستیم این ثبات ناشناخته 0x206040000 را تشخیص دهیم و همچنین کشف کردیم که دقیقاً چه چیزی در محدوده آدرس 0x206000000–0x206050000 نگاشت شده است.

ما توانستیم تابع ml_dbgwrap_halt_cpu را از کد شبه بالا با تابعی با همان نام در فایل dbgwrap.c کد منبع XNU مطابقت دهیم. این فایل حاوی کد کار با رجیسترهای اشکال زدایی ARM CoreSight MMIO CPU اصلی است. کد منبع بیان می‌کند که چهار منطقه MMIO مرتبط با CoreSight وجود دارد که ED، CTI، PMU و UTT نام دارند. هر کدام 0x10000 بایت را اشغال می‌کند و همه آنها در کنار یکدیگر قرار دارند. تابع ml_dbgwrap_halt_cpu از ناحیه UTT استفاده نموده و کد منبع بیان می‌کند که برخلاف سه مورد دیگر، از ARM نمی‌آید، بلکه یک ویژگی اختصاصی اپل است که فقط برای راحتی اضافه شده است.

با نوشتن ARM_DBG_LOCK_ACCESS_KEY در محل مربوطه، توانستیم تأیید کنیم که 0x206000000–0x206050000 در واقع بلوکی از ثبت‌های اشکال زدایی CoreSight MMIO برای پردازنده گرافیکی مشترک است. هر هسته از CPU اصلی بلوک خود را از رجیسترهای اشکال زدایی CoreSight MMIO دارد، اما برخلاف پردازنده‌های همکار GPU، آدرس‌های آن‌ها را می‌توان در درختچه دستگاه پیدا کرد. همچنین جالب است که نویسندگان این اکسپلویت می‌دانستند که چگونه از منطقه اختصاصی Apple UTT برای باز کردن CPU استفاده کنند: این کد بخشی از کد منبع XNU نیست. شاید منصفانه باشد که بگوییم این را می‌توان به راحتی از طریق آزمایش کشف کرد.

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

رجیسترهای 0x206140008 و 0x206140108 فعال/غیرفعال کردن و اجرای ویژگی سخت افزاری مورد استفاده توسط اکسپلویت را کنترل می‌کنند.

ثبات 0x206150020 فقط برای SoC های اپل A15/A16 Bionic استفاده می‌شود. در مرحله اولیه سازی اکسپلویت روی 1 و در مرحله نهایی‌سازی به مقدار اولیه آن تنظیم می‌شود. ثبات 0x206150040 برای ذخیره برخی پرچم‌ها و نیمه پایینی آدرس فیزیکی مقصد استفاده می شود.

آخرین ثبات، 0x206150048، برای ذخیره داده‌هایی که باید نوشته شود و نیمه بالایی آدرس فیزیکی مقصد، همراه با هش داده و مقدار دیگری (احتمالاً یک دستور) استفاده می شود. این ویژگی سخت‌افزاری داده ها را در بلوک‌های تراز شده 0x40 بایت می نویسد و همه چیز باید در 9 نوشتن متوالی در رجیستر 0x206150048 نوشته شود.

تا زمانی که همه چیز به درستی انجام شود، سخت افزار باید عملیات دسترسی مستقیم به حافظه (DMA) را انجام دهد و داده ها را در محل درخواستی بنویسد. این اکسپلویت از این ویژگی سخت افزاری به عنوان یک بای پس لایه حفاظتی صفحه PPL)  ) استفاده می‌کند که عمدتاً برای پچ ورودی‌های جدول صفحه است. همچنین می تواند برای پچ داده‌ها در بخش محافظت شده __PPLDATA استفاده شود. این اکسپلویت از این ویژگی برای پچ کد هسته استفاده نمی‌کند، اما یک بار در طول آزمایشی، توانستیم دستورالعملی را در بخش __TEXT_EXEC هسته بازنویسی و یک "دستورالعمل کرنل تعریف نشده" را با آدرس و مقدار مورد انتظار دریافت کنیم. این فقط یک بار جواب داد - دفعات دیگری که امتحان کردیم دچار وحشت AMCC شدیم. ما ایده‌ای در مورد اینکه یک بار درست انجام دادیم داریم، و قصدمان این است که در آینده عمیق تر به این موضوع نگاه کنیم، زیرا به نظرمان بسیار جالب خواهد بود که آسیب‌پذیری را که برای آسیب رساندن به ما استفاده شده است برداریم و از آن برای چیزی خوب، مانند فعال کردن اشکال زدایی هسته در آیفون های جدید استفاده کنیم.

اکنون که تمام کار با همه رجیسترهای MMIO پوشش داده شده است، اجازه دهید نگاهی به آخرین مورد بیندازیم: نحوه محاسبه هش‌ها.

این یک الگوریتم سفارشی است و هش با استفاده از جدول sbox از پیش تعریف شده محاسبه می‌شود. سعی کردیم آن را در مجموعه بزرگی از باینری ها جستجو کنیم، اما چیزی پیدا نکردیم. ممکن است متوجه شوید که این هش چندان ایمن به نظر نمی‌رسد، زیرا فقط 20 بیت را اشغال می‌کند (10+10، زیرا دو بار محاسبه می‌شود)، اما تا زمانی که هیچ کس نمی‌داند چگونه آن را محاسبه و استفاده کند، کار خود را انجام می‌دهد. به بهترین وجه با عبارت "امنیت با ابهام" خلاصه می شود. اگر از آن استفاده نشود و هیچ دستورالعملی در سیستم عامل در مورد نحوه استفاده از آن وجود نداشته باشد مهاجمین چگونه می‌توانند این ویژگی سخت افزاری را کشف کرده و از آن سوء استفاده کنند؟

در تحقیق دیگری متوجه شدیم که تراشه M1 داخل مک نیز دارای این ویژگی سخت افزاری ناشناخته است. سپس از ابزار شگفت انگیز m1n1 برای انجام آزمایشی استفاده کردیم. این ابزار دارای یک تابع trace_range است که تمام دسترسی ها به محدوده ارائه شده از ثبات های MMIO را ردیابی می‌کند. ما از آن برای تنظیم ردیابی برای محدوده حافظه 0x206110000–0x206400000 استفاده کردیم، اما هیچ کاربردی از این ثبات ها توسط macOS گزارش نشد.

در ارائه با عنوان "هک درایوهای بلو-ری سونی پلی استیشن"، به این مبحث پرداخته شده که چگونه توانستیم سیستم عامل را تخلیه کنیم و با استفاده از رجیسترهای MMIO DMA که از طریق درایوهای بلوری سونی پلی استیشن 3 و 4 در دسترس بودند، با استفاده از رجیسترهای MMIO DMA که با فرمان‌های scsl می‌شد به آن‌ها دسترسی پیدا کرد به اجرای کد دست یابیم.  

قادر شدیم این آسیب‌پذیری را کشف و اکسپلویتش کنیم، زیرا نسخه های قبلی سیستم عامل از این ثبات‌ها برای تمام عملیات DRAM استفاده می‌کردند، اما پس از آن سونی استفاده از آنها را متوقف و شروع به دسترسی مستقیم به DRAM کرد، زیرا تمام DRAM نیز به فضای آدرس CPU نگاشت شده بود. چون دیگر کسی از این رجیسترها استفاده نمی‌کرد و ما می‌دانستیم چگونه از آنها استفاده کنیم از این رو نیازی به دانستن الگوریتم هش مخفی نداشتیم.

آیا ممکن است در این مورد چنین اتفاقی بیفتد؟ نمی‌دانیم اما این پردازنده گرافیکی برای اولین بار در SoCهای اخیر اپل ظاهر شد. به نظر شخصی ما، بر اساس تمام اطلاعاتی که در بالا ارائه کردیم، بسیار شک داریم که این ویژگی سخت افزاری قبلاً برای هر چیزی در سفت‌افزار استفاده شده باشد. با این وجود، این احتمال وجود دارد که قبلاً به اشتباه در برخی از نسخه‌های سیستم عامل خاص یا کد منبع XNU آشکار شده و سپس حذف شده باشد.

امید داشتیم با رفع این آسیب‌پذیری که در iOS 16.6 پیاده‌سازی شده است، پی ببریم در دومین منطقه ناشناخته قرار دارد. متوجه شدیم اپل چگونه این مشکل را کاهش داده است، اما آنها این مشکل را مبهم کردند. اپل این آسیب‌پذیری را با افزودن محدوده‌های MMIO 0x206000000–0x206050000 و 0x206110000–0x206400000 مورد استفاده توسط اکسپلویت به محدوده‌های pmap-io- ذخیره شده در درختچه دستگاه کاهش داد. XNU از اطلاعات ذخیره شده در آنجا استفاده می‌کند تا تعیین کند آیا می‌توان نگاشت آدرس های فیزیکی خاصی را مجاز دانست یا خیر. همه ورودی های ذخیره شده در آنجا دارای یک نام برچسب معنی‌دار هستند که توضیح می‌دهد محدوده به چه نوع حافظه‌ای تعلق دارد. در نظر داشته باشید منظور از pcle همان Peripheral Component Interconnect Express و dart همان Device Address Resolution Table است و DAPF نیز به معنای Device Address Filter می‌باشد.

جمع‌بندی

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

منبع: کسپرسکی آنلاین (ایدکو)

کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.