نگاه فنی و موشکافانه به پروژه جاسوسی iMessage سازمان NSO: حمله صفر-کلیک
پیش گفتار سیسوگ:
چند ماه پیش، خبرهای تکان دهندهای از نرمافزاری مربوط به شرکت NSO منتشر شد که این نرمافزار توانایی داشت به کمک ارسال یک پیام به گوشی فرد قربانی، بدون اینکه حتی شخص دریافت کننده نیاز به انجام عملیات خاصی داشته باشه گوشی اون شخص را هک و در کنترل کامل خودش دربیاره.
این هک که میتونست در بالاترین دسترسی در گوشی قربانی قرار به گیره، تمام اطلاعات گوشی شخص را به سرقت برده و حتی مجوز فیلمبرداری و روشن کردن میکروفن را هم دارا بود و گوشیهای آیفون و اندروید را هم میتونست مورد حمله قرار بده.
هک گوشی مدیرعامل آمازون و خاشقچی و تعداد زیادی شخصیت سیاسی و معروف جهانی از جمله موارد مهمی بود که در موردش صحبت شده و این نفوذ آنچنان پیچیده، خاص و گسترده بود که حتی دولت آمریکا هم این شرکت اسرائیلی را تحریم کرد.
بررسی چنین موردهایی از نظر فنی میتونه خیلی جذاب و در عین حال آموزنده و هیجان انگیز باشه.
نکته جالب این هک که مفصل در متن خواهید دید استفاده از یک باگ کوچک هست که میتونه باعث آورفلوی رم بشه و در اونجا با استفاده از نحوه فشرده سازی تصاویر بتونن زیر ساخت ایجاد یک گیت منطقی ساده را داشته باشند و بعد با استفاده از همین ساختار، یک زبان برنامه نویسی خیلی کوچک نوشته بشه که بتونن هر آنچه میخواهند در گوشی قربانی انجام بدند!
جالبه بدونید شبیه چنین نفوذی در بوت لودر STM32 ها هم میتونه اتفاق بیفته که باعث میشه کل فایل برنامه شما را حتی با اینکه میکرو قفل شده بازیابی کرد که انشا الله در آینده در مورد اون هم صحبت کنیم.
iMessage نرم افزار دریافت و ارسال پیامک در گوشی های آیفون می باشد
اوایل امسال، Citizen Lab موفق به ردیابی یک سوءاستفاده سایبری صفر-کلیک بر پایه iMessage شد که برای هدف قرار دادن یک فعال سیاسی سعودی به کار گرفته شده بود.
جزییات این نوع سوءاستفاده در این مقاله دو بخشی شرح داده خواهد شد.
براساس تحقیقات انجام شده و نتاج بدست آمده، این مورد از نظر فنی یکی از بالاترین سطح از نفوذهایی است که تابحال دیده شده است. این امر نشان دهنده تواناییهای NSO در این زمنیه است. توناییهایی که در گذشته تصور میشد تنها کشورهای بسیار محدودی آنها را در اختیار داشته باشند.
لازم به ذکر است که نقطه ضعف امنیتی شرح داده شده در اینجا، در تاریخ 13 سپتامبر 2021 و در ورژن 14.8 سیستم عامل iOS اصلاح شده است.
NSO
تیم NSO یکی از شناختهشدهترین تولید کنندههای پکیجها و ابزارهای هک است که به کشورهای فاقد پیشزمینه و توانایی سایبری قابلیت خرید و استفاده از این قابلیتها را داده است. پس میتوان گفت در نتیجه فعالیت این گروه، تعداد کشورهای دارای تواناییهای سایبری به شدت افزایش پیدا کرده است.
در طول چندین سال گروههایی مثل Citizen Lab و Amnesty International، فعالیتهای مربوط به نرمافزار جاسوسی NSO به نام پگاسوس را ردیابی کردهاند. جالب است که با وجود ادعای NSO مبنیبر اینکه در خصوص سوءاستفادههایی که از تولیدات آنها میشود و تاثیرات بالقوه آن در نقض حقوق بشر، تحقیق و ارزیابی میکنند، رد پگاسوس در بسیاری از موارد این چنینی از جمله هک بن هابرد، روزنامهنگار نیویورک تایمز، توسط رژیم سعودی، هک مدافعین حقوق بشر در مراکش و بحرین، مورد هدف قرار دادن اعضای Amnesty International و موارد بیشمار دیگری گزارش شده است.
اخیرا ایالات متحده آمریکا NSO را به “لیست نهادها” اضافه کرد، که در نتیجه آن شرکتهای آمریکایی برای تبادل با این گروه به شدت محدود شدهاند. همچنین این دولت اعلام کرده است که ابزارهای NSO دولتها را قادر ساخته است که حتی فراتر از مرزهای خود اعمال قدرت کنند که مصداق آن، مورد هدف قرار دادن معترضان، روزنامهنگارها و فعالان سیاسی در خارج از مرز اینن کشورها و با هدف ساکت کردن اعتراضات است.
گروه Citizen Lab موفق شده است که نفوذ و سوءاستفاده پگاسوس در یک گوشی iPhone را ردیابی و استخراج کند و از تحلیل آن، از تواناییهای NSO نسبت به iPhone پرده بردارد.
در خصوص فروش نرمافزارهای جاسوسی با قابلیتهای صفر-کلیک مشابه، توسط NSO اطمینان وجود دارد. اما نمونهای از نفوذ و سواستفاده این چنینی از آن در دسترس نیست.
*توضیح در مورد صفر-کلیک (zero-click): برخلاف بدافزارها یا نرمافزارهایی که برای نفوذ مستلزم این هستند که کاربر روی لینک خاصی کلیک کند یا به وبسایت خاصی برود، در روش صفر-کلیک بدون هیچ کلیکی نفوذ صورت میگیرد!
از یک به صفر
در گذشته و در مواردی مثل دزدی میلیون دلاری در سال 2016، متن حاوی لینکهایی برای قربانیها sms شد؛
دریافت کننده پیام تنها زمانی هک میشود که روی لینک کلیک کند. این تکنیک با نام سوءاستفاده یک-کلیک شناخته میشود. اما اخیرا اثبات شده است که NSO به مشتریان خود تکنولوژی صفر-کلیک را ارائه میکند.
در این روش حتی افراد آگاهی که روی لینکهای فیشینگ کلیک نمیکنند، بدون آنکه روحشان نیز خبر داشته باشد مورد هدف قرار میگیرند. در سناریوی صفر-کلیک، احتیاج به هیچ تعاملی از سوی کاربر وجود ندارد. به بیان دیگر، سوءاستفادهگر نیاز به فرستادن پیام فیشنگ ندارد؛ همه کار در خاموشی و پسزمینه انجام خواهد شد. بنابرین هیچ راهی برای جلوگیری از این نوع نفوذ و سوءاستفاده وجود ندارد. حملهای که در برابر آن هیچ دفاعی ممکن نیست!
یک حقه عجیب
نقطه آغازین ورود پگاسوس به آیفون iMessage است. یعنی کاربر تنها با استفاده از شماره تلفن یا نام کاربری ApplieID مورد هدف قرار میگیرد.
iMessage به طور ذاتی از تصاویر GIF یا همان تصاویر متحرک با حجم و کیفیت پایین (خصوصا محبوب در دنیای میم)، پشتیبانی میکند. در iMessage امکان ارسال و دریافت GIF در چت وجود دارد و در همان پنجره چت نمایش داده میشوند. شرکت اپل در نظر داشت که نمایش GIFها به صورت حلقه بیپایان باشد و تنها یک مرتبه اجرا نشوند. بنابراین در مراحل ابتدایی در خط لوله تجزیه و پردازش iMessage، یعنی بعد از دریافت پیام و قبل از نمایش آن، برنامه متد زیر را در پروسه IMTranscoderAgent (در خارج از قطعه برنامه “BlastDoor”) فراخوانی میکند و هر فایل تصویری دریافتی با فرمت .gif را به آن میدهد؛
[IMGIFUtils copyGifFromPath:toDestinationPath:error]نام سکتور نشان میدهد که احتمالا در اینجا هدف، فقط کپی کردن فایل GIF، قبل از ویرایش بخش شمارش حلقه بوده است، اما منطق و کار این متد چنین نیست. در اینجا در واقع از APIهای CoreGraphics برای رندر کردن عکس منبع به یک فایل GIF جدید در مقصد، استفاده میشود. نکتهای که وجود دارد این است که تنها به دلیل وجود پسوند .gif در نام فایل منبع، نمیتوان گفت که واقعا یک فایل GIF است.
کتابخانه ImageIO، که برای حدس فرمت صحیح فایل منبع و تجزیه آن استفاده میشود، پسوند فایل را نادیده میگیرد. این درحالی است که به وسیله همین حقه GIF قلابی، روش حمله صفر-کلیک iMessage شامل بیش از 20 کدک تصویر میشود. برخی از آنها فرمتهای پیچیده و نامشخصی هستند که از راه دور (احتمالا) صدها هزار خط کد را اعمال میکنند.
یک PDF درون GIF
NSO از حقه GIF قلابی استفاده میکند و نقطه ضعف تجزیه PDF در CoreGraphics را هدف قرار میدهد.
حدود ده سال پیش، PDF به دلیل همهگیری و پیچیدگی، یک فرمت محبوب برای سوءاستفاده محسوب میشد. به علاوه، در دسترس بودن javascript درون PDFها، امکان توسعه قابل اطمینان کدهای سوءاستفادهگر را بسیار راحت میکرد. تجزیهکننده PDF در CoreGraphics، javascript را ترجمه نمیکند اما NSO موفق شد که درون این تجزیهکننده چیزی پیدا کند که به همان اندازه قدرتمند باشد..
فشردهسازی شدید
در اواخر دهه 1990، پهنای باند و فضای ذخیرهسازی نسبت به حال، بسیار محدود بودند. در چنین فضایی، استاندارد JBIG2 ظهور کرد. JBIG2 یک کدک تصویر حوزه خاص بود که برای فشردهسازی تصاویر سیاه و سفید، طراحی شده بود.
این استاندارد برای رسیدن به نرخ فشردهسازی بسیار بالا برای اسکن اسناد نوشتاری توسعه داده شد و در دستگاههای اسکنر/پرینتر مثل XEROX WorkCenter (شکل زیر) پیادهسازی شد. در هنگام استفاده از قابلیت scan to pdf چنین دستگاهی، احتمالا PDF حاصل شامل یک رشته JBIG2 میشد.
فایلهای PDF تولید شده توسط این اسکنرها، بسیار کم حجم بودند (تا حدود چند کیلوبایت). JBIG2 از دو تکنیک خلاقانه برای دستیابی به این نرخهای فشردهسازی استفاده میکند که با سوءاستفادهی مذکور مربتط هستند؛
تکنیک اول: بخشبندی و جایگزینی
تقریبا تمامی اسناد متنی، به خصوص موارد نوشته شده به زبانهای با حروف کوچک (مثل انگلیسی یا آلمانی)، از تعداد زیادی حروف تکراری در هر صفحه، تشکیل میشوند (که به glyph نیز معروفاند). JBIG2 هر صفحه را به glyphها تقسیم میکند و سپس از یک تطبیق الگوی ساده، برای جفت کردن glyphهایی که شبیه هم هستند استفاده میکند؛
در واقع JBIG2 خود glyphها را نمیشناسد و عمل تشخیص متن (OCR) انجام نمیدهد. انکدر JBIG تنها به دنبال ناحیههای به هم متصل پیکسلها میگردد و نواحی مشابه را در یک گروه قرار میدهد. هدف الگورتیم فشردهسازی، جایگزین کردن همه نواحی مشابه هم با یکی از آنهاست؛
بنابراین، نتیجه کار خوانا است و میزان اطلاعاتی که باید ذخیره شود به میزان قابل توجهای کاهش یافته است. به این طریق، دیگر نیازی به ذخیره همه اطلاعات اصلی پیکسلهای صفحه نیست و تنها باید یک نسخه فشرده شده از “glyph مرجع” برای هر حرف و همچنین مختصات نسبی مکان همهی تکرارهای آن ساخته شود. به همین طریق الگوریتم غیرفشردهسازی در صفحه خروجی، هر glyph را در مکانهای ذخیره شده “ترسیم” میکند.
اما در این نقشه یک اشکال بزرگ وجود دارد؛ یک انکدر ضعیف ممکن است تصادفا دچار اشتباه شده و حروف مشابه را جابهجا کند. البته مشکلات این روش در اینجا بررسی نمیشود اما دلیل اینکه JBIG2 دیگر یک فرمت فشرده سازی معمول نیست را روشن میسازد.
تکنیک دوم: کدینگ اصلاح
همانطور که پیشتر نیز گفته شد، عمل فشردهسازی بر پایه جایگزینی، دارای تلفات است. بدین معنی که بعد از یک بار فشردهسازی و سپس غیرفشردهسازی، خروجی رندر شده دقیقا مانند ورودی نخواهد بود. با این حال، JBIG2 شامل یک حالت فشردهسازی بدون تلفات و یک حالت میانهِ “با تلفات کمتر” نیز میشود.
این عمل با ذخیره کردن (و فشردهسازی) اختلاف بین glyph جایگزین شده و glyphهای اصلی میشود. در مثال زیر بین یک حرف جایگزین شده و حرف اصلی بدون اتلاف دیده میشود؛
در این مثال ساده، انکدر میتواند تفاوت محاسبه شده در راست را ذخیره کند و سپس هنگام غیرفشردهسازی، مجددا این تفاوت با حرف جایگزین شده XOR شود تا دقیقا همان حرف اصلی نتیجه گردد. همچنین از ترفندهای دیگری نیز برای فشردهسازی بیشتر تصویر تفاوت استفاده میشود که خارج از حوصله این مقاله است.
عمل انکد کردن اختلاف، همچنین میتواند در چند مرحله انجام شود. بدین صورت که در هر پله، از یک عملگر منطقی (یکی از عملهای AND، OR، XOR یا XNOR) استفاده و بیتها یک، صفر یا متمم شوند. پس در هر مرحله از اصلاح نتیجه خروجی به تصویر اصلی نزدیک و نزدیکتر میشود. این عمل یک درجه کنترل بر میزان اتلاف فشردهسازی به دست میدهد. پیادهسازی این مراحل کدینگ اصلاح، بسیار انعطافپذیر است و همچنین امکان خواندن مقادیر حاضر در خروجی در هر زمان وجود دارد.
یک رشته JBIG2
اکثر بخشهای کد PDF دیکدر CoreGraphics در مالکیت و اختیار شرکت اپل است اما پیادهسازی JBIG2 توسط Xpdf است و سورسکد آن را به صورت رایگان در دسترس قرار داده است.
فرمت JBIG2 تشکل شده از یک سری سگمنتهاست که میتوان آنها را به صورت یک سری دستورات ترسیم تصور کرد که باید پشت سر هم اجرا شوند. تجزیهکننده JBIG2 دز CoreGraphics از 19 نوع مختلف سگمنت پشتیبانی میکند که شامل عملهایی مثل تعریف یک صفحه جدید، دیکد کردن یک جدول هافمن و یا رندر کردن یک Bitmap به مختصات داده شده در صفحه میشوند.
این سگمنتها توسط کلاس JBIG2Segment یا زیرکلاسهای آن یعنی JBIG2Bitmap و JBIG2SymolDict ارائه میشوند.
یک JBIG2Bitmap ارائهکنندهی آریهای مستطیلی از پیکسلهاست. فیلد دادهی آن به یک Backing-Buffer اشاره میکند که شامل خروجی در حال رندر میشود.
همچنین یک JBIG2SymbolDict، در واقع JBIG2Bitmapها را با هم گروهبندی میکند. صفحه مقصد و glyphها به صورت یک JBIG2Bitmap ارائه میشوند.
و در آخر، ارجاع به JBIG2Segmentها توسط یک شماره سگمنت صورت میگیرد و همچنین اشارهگرها به همهی JBIG2Segmentها در بردار GList ذخیره میشود. برای پیدا کردن هر سگمنت توسط شماره سگمنتها، GList به شکل ترتیبی اسکن میشود.
نقطه ضعف
نقطه ضعف در واقع یک آورفلوی عدد صحیح است که در جمعآوری و ترکیب سگمنتهای مورد ارجاع اتفاق میافتد.
numSyms یک عدد صحیح 32بیتی است که در (1) اعلان شده است. در صورت فراهمکردن سگمنتهای مرجعی که دقیق طراحی شده باشند، امکان ایجاد آورفلوی numSyms به یک مقدار کوچک کنترل شده، وجود دارد.
این مقدار کوچکتر برای تنظیم اندازه heap در (3) استفاده میشود. بدین معنی که syms به یک بافر با اندازه کوچکتر اشاره میکند.
درون داخلیترین حلقه، در (4)، مقدارهای اشارهگر JBIG2Bitmap درون بافر کوچک syms نوشته میشوند.
بدون هیچ ترفند دیگری، این حلقه بیش از 32 GB داده را درون بافر کوچک syms خواهد نوشت که بدون شک موجب از کارافتادن سیستم میشود. برای جلوگیری از این اتفاق، نحوه نوشتن اطلاعات در حافظه heap و بافر های sym و GList بصورت هوشمندانه ای مدیریت می شود.
وظیفه GList نگهداری segmentهای شناخته شده است و توسط روال findSegments برای نگاشت شماره سگمنتهای ورودی refSegs به اشارهگرهای JBIG2Segment استفاده میشود. در (4) آورفلویی که راجع به آن صحبت کردیم موجب میشود که اشارهگرهای JBIG2Segment در GList توسط اشارهگرهای JBIG2Bitmap بازنویسی شوند.
به این طریق، از آنجا که JBIG2Bitmap وارث JBIG2Segment است، فراخوانی مجازی seg -> getType() حتی روی دستگاههایی که احراز اشارهگر (که یک بررسی ضعیف روی فراخوانیهای مجازی انجام میدهد) فعال باشد، به سادگی امکان وقوع پیدا میکند. اما اکنون type بازگشتی با jbig2SegSymbolDict برابر نخواهد بود، که در نتیجه موجب میشود که در (4)، نوشتنهای بعدی صورت نگیرند و میزان خرابی حافظه به این صورت محدود شود.
بیمرز کردن بدون حد!
دقیقا بعد از اتمام کار اختلال در سگمنتهای GList، حملهکننده به سراغ تغییر شیء JBIG2Bitmap میرود. این شیء صفحه کنونی را نشان میدهد که جایی است که دستورات ترسیم فعلی، رندر میشوند.
JBIG2Bitmapها مانند پوشش سادهای اطراف یک بافر پشتیبان هستند و وظیفه آنها ذخیره عرض و ارتفاع بافر (در قالب بیت) و همچنین یک مقدار خط است، که تعیین میکند در هر خط چند بایت ذخیره شود.
با معماری دقیق refSegs امکان متوقف کردن آورفلو وجود دارد، که این کار را دقیقا پس از نوشتن سه اشارهگر JBIG2Bitmap دیگر، بعد از انتهای بافر سگمنتهای GList، انجام میدهند. این عمل، موجب بازنویسی اشارهگر vtable و چهار حوزهی اولیهی JBIG2Bitmap، که نشان دهنده صفحه کنونی هستند، خواهد شد. بدلیل طبیعت آرایش فضای آدرس در iOS، این اشارهگرها در 4GB دوم حافظه مجازی با آدرس 0x100000000 تا 0x1ffffffff قرار میگیرند. از طرف دیگر تمامی سخت افزار iOS به صورت little endian یا حروف کوچک است، بدین معنی که حزوههای w و line احتمالا با 0x1 – نیمه پرارزش اشارهگر JBIG2Bitmap- بازنویسی میشوند. همچنین حوزههای segNum و h نیز احتمالا با نیمه کمارزش اشارهگر بازنویسی میشوند. این نیمه کمارزش بسته به آرایش heap و ASLR مقداری بین 0x100000 تا 0xffffffff دارد.
بنابراین صفحه مقصد فعلی JBIG2bitmap یک مقدار نامعین اما بسیار بزرگ برای h خواهد گرفت. و از آنجایی که مقدار h برای چک کردن محدودیتها استفاده میشود و اندازه بافر پشتیبان صفحه را مشخص میکند، نتیجه این کار بی حد و مرز ساختن عمل ترسیم است. بدین معنی که دستورات بعد سگمنت JBIG2 توانایی خواندن و نوشتن فراتر از حدود تعریف شده اصلی برای بافر پشتیبان صفحه را دارند!
علاوه بر این در هنگام دستکاری heap، بافر پشتیبان صفحه فعلی دقیقا زیر بافر syms کوچک شده قرار داده میشود. به طوریکه هنگام بدون مرز ساختن صفحه JBIG2Bitmap، توانایی خواندن و نوشتن در حوزههای خودش را نیز پیدا خواهد کرد؛
با رندر کردن bitmapهای 4-بایتی در مختصات صحیح، حملهکننده امکان نوشتن در تمامی حوزههای صفحه JBIG2Bitmap را خواهد داشت، و با انتخاب دقیق مقادیر w، h و line، همچنین میتواند در هر آفست دلخواهی از بافر پشتیبان صفحه، امکان نوشتن داشته باشد.
در این مرحله، در صورت دانستن آفست هر آدرسی از حافظه نسبت به بافر پشتیبان صفحه، امکان نوشتن در آن آدرس وجود خواهد داشت. اما سوال این است که این آفستها چگونه باید محاسبه شوند؟ تا اینجای کار عمل سوءاستفاده رفتاری مشابه سوءاستفادهی یک زبان اسکریپنویسی “canonical” دارد که در Javascript ممکن است به یک شیء بافر آرایهی بی حد و حصر ختم شود که به حافظه دسترسی دارد. اما در آن موارد، حملهکننده امکان استفاده از Javascript دلخواه برای محاسبه آفست و محاسبات دیگر را خواهد داشت. پس این عمل فقط به وسیلهی یک تجزیه کننده عکس single-pass چگونه ممکن است؟
فرمت فشردهسازی دیگری در حال تکمیل است!
پیشتر اشاره شد که سلسله مراحل پیادهسازی اصلاح JBIG2 بسیار انعطافپذیراند. مراحل اصلاح توانایی ارجاع به bitmap خروجی و هر سگمنتی که قبلا ساخته شده را دارند. همچنین این امکان را دارند که خروجی را به صفحه فعلی یا یک سگمنت رندر کنند. با طراحی دقیق بخشی از غیرفشردهسازی اصلاحی که وابسته به محتواست، میتوان سلسلهای از سگمنتها ساخت که در آن ترکیب عملگرهای اصلاح، هر تاثیر دلخواهی را داشته باشد.
در عمل، این موضوع امکان استفاده از عملگرهای منطقی AND، OR، XOR و XNOR را بین نواحی حافظه در هر آفست دلخواهی نسبت به بافر پشتیبان JBIG2Bitamap صفحهی فعلی، به وجود میآورد. و از آنجا که این بافر بدون مرز شده بود، انجام عملیات منطقی در آفستهای حتی خارج از حدود در حافظه، امکانپذیر میشود.
زمانی که این موضوع به شدیدترین حالت خود درآید، همه چیز جالبتر میشود. به این موضوع فکر کنید که اگر به جای انجام عملیات رو قطعههای در اندازه glyph، عملیات روی تک بیت انجام شود چه خواهد شد؟
در این صورت میتوان رشتهای از دستورات سگمنت JBIG2 که یک رشته عملیات منطقی بیتی روی صفحه انجام میدهند را به عنوان ورودی ایجاد کرد. و از آنجا که بافر صفحه بدون مرز شده است، این عملیات بیتی روی حافظه دلخواه قابل اعمال هستند.
با یک حساب و کتاب ساده میتوان پی برد که تنها با در دسترس بودن عملگرهای منطقی AND، OR، XOR و XNOR میتوان هر تابع محاسباتی دلخواهی را ایجاد کرد. به عنوان یک اثبات ساده برای این موضوع، میتوان گفت که ساختن مثلا یک گیت NAND با استفاده از یک گیت XOR (یک ورودی آن منطق 1 است) و یک گیت AND امکانپذیر است؛
مدارهای کاربردی
میدانیم که خود JBIG2 قابلیتهای اسکریپ نویسی ندارد اما با وجود یک نقطه ضعف در آن، میتوان برای گیتهای منطقی دلخواه، مدارهایی شبیهسازی کرد و به وسیلهی آنها روی حافظه دلخواه عملیات انجام داد. پس به همین طریق میشود معماری کامپیوتر مورد نظر را پیاده کرد و برای آن اسکریپت نوشت! که همان کاری است که در این سوءاستفاده انجام شده است. حملهکننده ها به وسیله 70000 دستور سگمنت که عملیات منطقی بیتی را تعریف میکنند، موفق شدند یک معماری کوچک کامپیوتر تعریف کنند که شامل رجیسترها و یک جمعکننده و مقایسه کننده 64 بیتی میشود. سپس به این طریق توانایی جست و جوی حافظه و انجام عملیات ریاضی را داشتند. این عمل شاید به سرعت Javascript نباشد اما اساسا از نظرمحاسباتی تفاوتی نخواهد داشت.
برای انجام سوءاستفاده از طریق فرار از sandbox، عملیات بوتاسترپ نوشته میشود که روی این مدار منطقی اجرا شوند. تمامی کار روی همین محیط شبیهسازی شده نامتعارف اجرا میشود (که از یک فشردهسازی که از طریق JBIG2 عمل میکند، ساخته شده است). باید گفت که بسیار ظریف و زیبا انجام شده است و در عین حال، بسیار ترسناک است.
در قسمت آینده در مورد چگونگی فرار از سندباکس IMTransoderAgent شرح داده خواهد شد.
خیلی جذاب بود
ممنون از شما
خواهش میکنم. مرسی از همراهی و انرژی مثبت شما.
عالی بود خدا قوت
مرسی از همراهی و انرژی مثبتتون.
درود بر مهندس خفن عزیز
مطالبی که نوشتین واقعاً ترسناک و در عین حال هیجان انگیز بود امیدوارم که این شتر دم خونه کسی اتراق نکنه . به وجود شما با این سطح دانش افتخار میکنم همیشه پایدار باشید
عالی بود ممنون
خواهش میکنم. مرسی از همراهی شما
حقیقتا با خواندن این مقاله پشمی باقی نموند. به مرکز اپیلاسیون سیسوگ خوش آمدید. :))
اینم از قابلیتهای جدید سایته :))