تزریق خطای لیزر با هدایت گسیل فوتون، اشکال زدایی ایمن RP2350 را فعال می کند

- میکروسکوپ گسیل فوتون به ما این امکان را می دهد تا یک رجیستر مسئول فعال کردن ویژگی های اشکال زدایی در میکروکنترلر Raspberry Pi را پیدا کنیم.

- پالس‌های لیزر در دو موقعیت نزدیک، سپس دسترسی دیباگر را به دنیای امن تراشه بازیابی کرد، حتی اگر اشکال‌زدایی برای همیشه غیرفعال شده بود.

- با استفاده از این دسترسی پس از بازنشانی نجات، یک راز را از حافظه قابل برنامه ریزی یک بار بازیابی کردیم. تنظیم مجدد تراشه را قبل از اینکه سیستم عامل بتواند قفل زمان اجرا خود را اعمال کند متوقف کرد، بنابراین صفحه قابل خواندن امن باقی ماند.

RP2350 میکروکنترلر دو هسته ای Raspberry Pi است: هر سوکت پردازنده می تواند یک هسته Arm Cortex-M33 یا یک هسته RISC-V Hazard3 را در هنگام راه اندازی انتخاب کند. ویژگی های امنیتی سخت افزاری آن عبارتند از:

Raspberry Pi فعالانه از محققان دعوت کرده است تا از طریق چالش های هک RP2350 خود، این حفاظت ها را ارزیابی کنند. اولین چالش از آگوست تا دسامبر 2024 علیه تراشه اصلی اجرا شد. پس از بررسی چندین یافته، Raspberry Pi نسخه A4 را منتشر کرد - نسخه ای که ما آزمایش کردیم.

پیکربندی امنیتی دائمی و اثر انگشت کلید عمومی راه‌اندازی در حافظه یکبار برنامه‌ریزی (OTP) ذخیره می‌شوند: هر بیت را می‌توان یک بار از 0 به 1 برگرداند و هرگز به عقب برنگردید، بنابراین هر چیزی که در آنجا نوشته شده است برای طول عمر تراشه باقی می‌ماند.

OTP در صفحات 128 بایتی سازماندهی شده است که توسط دو ردیف قفل دائمی یا سخت محافظت می شوند: برای صفحه n، PAGEn_LOCK0 کلیدهای خواندن و نوشتن اختیاری و رفتار زمانی که هیچ کلیدی وارد نشده است را پیکربندی می کند، در حالی که PAGEn_LOCK1 حاوی مجوزهای LOCK_S و LOCK_NS است که توسط سخت افزار اعمال می شود. این حالت ها می توانند از خواندن-نوشتن به فقط خواندنی یا غیرقابل دسترسی پیش بروند، اما نمی توانند راحت تر شوند.

زیرسیستم OTP از رمزگذاری‌های اضافی برای فیلدهای مرتبط با امنیت استفاده می‌کند: پرچم‌های مهم «با رأی سه از هشت در هشت ردیف OTP متوالی کدگذاری می‌شوند»، و بیت‌های قفل OTP «سه‌گانه با اکثریت آرا»، طبق برگه داده RP2350، «کدگذاری می‌شوند».

در بازنشانی OTP، مقادیر ثابت LOCK_S و LOCK_NS یک قفل زمان اجرا در هر صفحه را که قفل نرم نیز نامیده می‌شود، مقداردهی اولیه می‌کنند. سفت‌افزار می‌تواند این قفل را تا تنظیم مجدد OTP بعدی محکم کند، اما نمی‌تواند آن را باز کند. تغییر زمان اجرا از این تنظیم مجدد دوام نمی آورد.

یک دیباگر خارجی با RP2350 از طریق واسط Arm’s Serial Wire Debug (SWD) ارتباط برقرار می کند. درخواست ها ابتدا به پورت اشکال زدایی سیم سریال (SW-DP) می رسند و سپس به پورت های دسترسی هدایت می شوند. در پیکربندی Cortex-M33 مورد استفاده در اینجا، هر هسته یک پورت دسترسی به حافظه (Mem-AP) متصل به گذرگاه سیستم خود دارد. یک Mem-AP فعال به دیباگر اجازه می دهد تا حافظه و تجهیزات جانبی مجاز را بخواند و بنویسد. یک پورت دسترسی همیشه روشن جداگانه، RP-AP، مجموعه کوچکی از کنترل‌های بازنشانی و بازیابی را نشان می‌دهد.

اشکال‌زدایی امن به دسترسی Mem-AP با ذکر منبع امن اشاره دارد. سپس اشکال‌زدا می‌تواند با منابع نقشه‌برداری حافظه امن که منطق کنترل دسترسی اجازه می‌دهد، تراکنش کند و هسته‌ای را که در حالت امن اجرا می‌شود متوقف یا بازرسی کند.

پرچم دائمی CRIT1.DEBUG_DISABLE برای بستن این مسیر در نظر گرفته شده است. وقتی تنظیم شود، سیگنال‌های فعال را برای Mem-APهای هر دو هسته به صفر می‌رساند، که «از انجام هرگونه دسترسی گذرگاهی به APها جلوگیری می‌کند» و رابط JTAG تست کارخانه و پورت دسترسی ماژول اشکال‌زدایی RISC-V را غیرفعال می‌کند. SW-DP و RP-AP هنوز پاسخ می دهند، اما هیچ یک از Mem-AP هسته ای نمی توانند به گذرگاه سیستم دسترسی داشته باشند.

با این حال، یک نادیده گرفتن وجود دارد: رجیستر DEBUGEN نقشه برداری شده با حافظه به نرم افزار Secure اجازه می دهد تا Mem-AP هر هسته را دوباره فعال کند و به طور جداگانه، Secure از طریق آن دسترسی داشته باشد. برگه داده بیان می‌کند که DEBUG_DISABLE «با تنظیم همه بیت‌های این ثبات می‌تواند به طور کامل لغو شود».

این نادیده گرفتن حیاتی در زنجیره اجرایی همان چیزی است که رابط اشکال زدایی را هدف ما قرار داده است. دسترسی به Secure debug در Mem-AP یک روش اولیه همه منظوره برای خواندن و نوشتن حافظه امن، توقف و تک مرحله یک هسته، و بازرسی رجیسترهای آن است. این که آیا این رجیستر ممکن است با یک خطا تنظیم شود یا خیر، سوالی است که بقیه این پست به آن پاسخ می دهد.

چالش هک RP2350 Raspberry Pi از شرکت کنندگان خواست تا یک راز 128 بیتی ذخیره شده در OTP 1 را استخراج کنند. هنگام راه‌اندازی، سفت‌افزار چالش امضاشده تضمین می‌کند که صفحه ۴۸ قفل دائمی مورد انتظار را دارد، سپس قفل زمان اجرا را اعمال می‌کند که تا زمان تنظیم مجدد OTP بعدی، دسترسی امن و غیرایمن را به راز ممنوع می‌کند.

ما این پیکربندی تعریف شده توسط فروشنده را در دستگاه A4 ویرایش شده خودمان تکرار کردیم:

فعال کردن راه‌اندازی ایمن فقط به هسته‌های Cortex-M33 اجازه می‌دهد، بنابراین هر دو سوکت پردازنده از Arm برای این آزمایش‌ها استفاده کردند.

پشت دستگاه کپسوله شده بود، به طوری که نور مادون قرمز از طریق بستر سیلیکونی به ترانزیستورها می رسد نه اینکه توسط لایه های فلزی در جلو مسدود شود. سپس تراشه بر روی یک تخته متصل به Scaffold، پلتفرم منبع باز Ledger Donjon برای رانندگی و نظارت بر دستگاه های تحت آزمایش، لحیم شد. برداشتن قاب سرب در پشت تراشه، اتصال GND آن را قطع می کند، بنابراین یک سیم مسی آن را بازیابی می کند.

اشکال‌زدایی امن در هسته به هر دو بیت آن نیاز دارد: بیتی که Mem-AP را فعال می‌کند و بیتی که اجازه دسترسی امن از طریق آن را می‌دهد.

برخلاف کدگذاری اضافی که برای فیلدهای امنیتی OTP استفاده می‌شود، برگه داده هیچ‌گونه افزونگی، برابری یا اکثریتی را برای DEBUGEN مستند نمی‌کند.

بنابراین ما آزمایش کردیم که آیا پالس های لیزر می توانند بیت های DEBUGEN را روی دستگاه ایمن که در بالا توضیح داده شد تنظیم کنند.

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

ترانزیستورهای سوئیچینگ فوتون های کم نور نزدیک به مادون قرمز را منتشر می کنند که با فعالیت آنها مرتبط است، بنابراین جمع آوری آن گسیل در اجرای مکرر می تواند نشان دهد که یک کنترل انتخابی در کجا تغییر حالت می دهد. این باعث شد که میکروسکوپ گسیل فوتون (PEM) برای DEBUGEN مناسب باشد: نرم افزار Secure به عنوان یک ثبات نقشه برداری حافظه می تواند بیت های دقیق را در یک حلقه تغییر دهد و حالت تکراری نیازهای اندازه گیری را تغییر می دهد. ما از آن به عنوان اولین مرحله محلی سازی استفاده کردیم و نقشه حاصل اسکن لیزری بعدی را به ناحیه ای چند میکرومتری محدود کرد.

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

به هم پیوستن این دو مقدار در حین اکتساب، باعث می‌شود که این تفریق به آرامی تغییر نکند. آنچه باقی مانده بود انتشار بود که بیت های انتخاب شده را ردیابی می کرد.

مقایسه‌های مکرر در بین ماسک‌های بیت مختلف، سایت‌های فشرده مرتبط با بیت‌های DEBUGEN 0-3 را در سه ناحیه از میدان دوربین نشان داد.

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

برای تزریق خطای لیزر (LFI)، ما از یک لیزر پالسی در 980 نانومتر با حداکثر توان نوری 2.97 W استفاده کردیم که تقریبا با 40٪ (حدود 1.2 وات) کار می کرد، با عرض پالس 100 ns از طریق یک شیئی 50 برابر. پس از هر پالس، پورت های دسترسی اشکال زدایی را روی SWD بررسی کردیم.

در ناحیه پیدا شده از PEM، ما یک اسکن LFI انجام دادیم و از بازخورد SWD برای کالیبره کردن دو موقعیت پاسخگو با فاصله چند میکرومتری از هم استفاده کردیم. در یک موقعیت، پالس ها دسترسی گذرگاه را از طریق Mem-AP هسته 1 فعال کردند، که نشان می دهد PROC1 تنظیم شده است. از سوی دیگر، Mem-AP's Control/Status Word SDeviceEn = 1 را گزارش کرد، یک سیگنال هدایت‌شده توسط حالت که احتمالا PROC1_SECURE تنظیم شده است. ما هر دو نشانگر را بعد از هر پالس بررسی کردیم.

پالسی که یک بیت را تنظیم می کند می تواند دیگری را پاک کند، بنابراین تنظیم هر دو به یک دنباله تکراری نیاز دارد. اسکریپت ما موقعیت PROC1 را تا زمانی که دسترسی گذرگاه در دسترس باشد پالس می‌کند، سپس موقعیت PROC1_SECURE را تا SDeviceEn = 1 پالس می‌کند، و هر زمان که دسترسی گذرگاه قطع می‌شد به موقعیت اول بازمی‌گردد. هنگامی که موقعیت ها و پارامترهای پالس کالیبره شدند، توالی اشکال زدایی ایمن را در عرض چند ثانیه فعال کرد. جالب اینجاست که ما نمی‌توانستیم این دنباله را با استفاده از یک هدف 20 برابری تولید کنیم.

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

هنگامی که هر دو بیت تنظیم شدند، بدون پالس های بیشتر یا نوشتن نرم افزار تنظیم می شوند. خواندن رجیستر DEBUGEN فقط امن از طریق Mem-AP هسته 1 و سپس 0xc برگردانده شد. از آنجایی که DEBUGEN فقط امن است، این خواندن موفقیت آمیز تایید می کند که تراکنش به صورت Secure نسبت داده شده است.

فعال کردن دسترسی‌های ایمن از طریق Mem-AP هسته 1 به دیباگر اجازه می‌دهد منابع نقشه‌برداری حافظه را بخواند و بنویسد که مجوزهای ACCESSCTRL اشکال‌زدا را به‌عنوان مدیر گذرگاه می‌پذیرد و کنترل‌های خاص هدف آن تراکنش‌های AHB ایمن را می‌پذیرد. مستقل از این خوانش‌های مستقیم، دیباگر می‌تواند هسته را متوقف و تک مرحله‌ای کند و رجیسترهای آن را بازرسی یا اصلاح کند، و جداسازی زمان اجرا TrustZone را از طریق استخراج با واسطه هسته امن به خطر بیاندازد.

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

دسترسی Secure-attributed Mem-AP که در بالا توضیح داده شد، وضعیت زمان اجرا امن را نشان می‌دهد، اما قفل زمان اجرا صفحه 48 چالش همچنان از دسترسی به راز پس از اجرای سیستم‌افزار جلوگیری می‌کند. قفل دائمی صفحه، PAGE48_LOCK1 = 0x3c3c3c، خواندن غیر ایمن را رد می‌کند، اما LOCK_S را در READ_WRITE می‌گذارد، بنابراین قبل از اینکه قفل زمان اجرا سفت شود، از طریق دسترسی‌های منتسب به Secure قابل خواندن باقی می‌ماند.

در طول هر بوت، سفت‌افزار محدودترین مقدار باینری، 0b1111 را روی قفل زمان اجرا otp_hw->sw_lock[48] می‌نویسد. پس از آن ثبت، صفحه را برای هر دو دسترسی ایمن و غیر ایمن، از جمله اشکال زدایی ایمن، غیرقابل دسترس می کند و بنابراین از خواندن راز از تراکنش های امن از Mem-AP جلوگیری می کند.

همانطور که مستند شده است، قفل‌های نرم‌افزاری «در هنگام بازنشانی از صفحات قفل OTP مقداردهی اولیه می‌شوند» و نوشتن فقط وضعیت «تا تنظیم مجدد بعدی» را پیش می‌برد. بازنشانی بلوک OTP 0b1111 را حذف می کند و مقدار مشتق شده از PAGE48_LOCK1 را بازیابی می کند که برای آن LOCK_S = READ_WRITE است.

سوال باقی مانده این است که چگونه یک تراشه قفل شده را بدون اجازه دادن به سیستم عامل برای اعمال مجدد قفل زمان اجرا، بازنشانی کنیم. RP-AP "همیشه در دسترس است، حتی زمانی که اشکال زدایی خارجی غیرفعال است". تنظیم CTRL.RESCUE_RESTART یک Rescue Reset را راه‌اندازی می‌کند: یک بازنشانی کامل سیستم که همچنین پرچم بوت رام را برای توقف قبل از اجرای هر نرم‌افزار کاربر نشان می‌دهد.

رام راه‌اندازی POWMAN_CHIP_RESET.RESCUE_FLAG را قبل از راه‌اندازی Watchdog، Flash یا USB بررسی می‌کند، آن را پاک می‌کند، سپس هسته 0 را در یک حلقه انتظار غیرفعال‌شده با وقفه و هسته 1 را در مسیر انتظار برای برداری نگه می‌دارد. 3 برگه داده هیچ محدودیتی در CTRL.RESCUE_RESTART ندارد.

ما این دنباله را روی دستگاه آزمایش شده اجرا کردیم و راز چالش کامل را بازیابی کردیم.

نرم‌افزار بلوک‌های DEBUGEN_LOCK به بیت‌های DEBUGEN مربوطه می‌نویسد: هر بیت قفل عبارت است از «برای قفل کردن […] بیت DEBUGEN 1 بنویسید. پس از تنظیم نمی‌توان آن را پاک کرد». دیتاشیت این را به عنوان راهی برای جلوگیری از نوشتن تصادفی ارائه می کند.

در آزمایش‌هایی با بیت DEBUGEN هدف در 0 و بیت قفل آن در 1، یک پالس همچنان می‌تواند DEBUGEN را تنظیم کند در حالی که قفل 1 باقی می‌ماند. پالس ها همچنین بیت های قفل را با یا بدون تغییر DEBUGEN مربوطه تنظیم می کنند. در توالی های موفق، هر پنج بیت قفل عملکردی تا زمانی که PROC1 و PROC1_SECURE هر دو تنظیم شدند، 1 بودند. ما هرگز شاهد بازگشت بیت قفل از 1 به 0 نبودیم، بنابراین نوشتن بعدی DEBUGEN = 0 نمی تواند حالت غیرفعال را پس از تنظیم قفل مربوطه توسط خطا بازیابی کند.

هنگامی که دسترسی‌های ایمن از طریق Mem-AP فعال می‌شوند، Secure etribution به تنهایی دیگر اشکال‌زدا را از میان‌افزار امن جدا نمی‌کند. این دسترسی قفل های OTP سخت یا کنترل های ویژه محیطی را لغو نمی کند. ACCESSCTRL می‌تواند تراکنش‌های مستقیم دیباگر-مدیر به اهداف خاص را مسدود کند، اما به خودی خود مانع از ایجاد دسترسی‌های مبدأ هسته یا استخراج مقادیر بارگذاری‌شده از طریق ثبات‌های اصلی، اشکال‌زدایی که هسته امن را کنترل می‌کند، نمی‌شود. پس از بازنشانی نجات، ACCESSCTRL قبل از اینکه سیستم عامل بتواند آن را مجددا پیکربندی کند، به پیش‌فرض‌های زمان بازنشانی کاملا باز خود برمی‌گردد.

بنابراین ACCESSCTRL قرار گرفتن در معرض مستقیم Mem-AP را به جای ایجاد یک مرز محرمانه مستقل کاهش می دهد.

با این حال، میان‌افزار می‌تواند با ممانعت از دسترسی دیباگر به اهداف حساس در ACCESSCTRL، و سپس تنظیم بیت دیباگر در ACCESSCTRL.LOCK، قرار گرفتن در معرض پس از راه‌اندازی را کاهش دهد تا تراکنش‌های دیباگر نتوانند آن مجوزها را دوباره باز کنند. سفت‌افزار امن همچنین می‌تواند DEBUGEN را به‌صورت دوره‌ای بررسی کند و در یک مقدار غیرمنتظره، بازنشانی بی‌خطر را راه‌اندازی کند که دامنه بازنشانی سرد پردازنده را پاک کند. این اقدامات بهترین کاهش زمان اجرا هستند: یک دیباگر فعال ممکن است قبل از بررسی بعدی، هسته را متوقف کند، و قبل از اینکه سیستم عامل بتواند ACCESSCTRL را پیکربندی کند یا نمایشگر را اجرا کند، بازنشانی متوقف می شود.

بنابراین آنها از خواندن مخفی پیش از سیستم عامل که در اینجا نشان داده شده است جلوگیری نمی کنند.

جریان بوت رمزگذاری شده مستند RP2350 محدودیت قفل‌های زمان اجرا قبل از سیستم عامل و محدودیت فیلتر دیباگر-مدیر پس از راه‌اندازی را در دو حالت ماشین مجزا نشان می‌دهد. پس از بازنشانی نجات، رام بوت قبل از رمزگشایی متوقف می‌شود: هنوز هیچ بار متن ساده‌ای وجود ندارد، اما اگر مجوزهای دائمی صفحه OTP اجازه دسترسی امن را بدهد و هیچ کنترل هدف دیگری تراکنش را مسدود نکند، ممکن است کلید رمزگشایی مستقیما قابل خواندن باشد.

پس از راه اندازی رمزگذاری شده معمولی، متن ساده در SRAM وجود دارد: خواندن مستقیم Mem-AP به مجوزهای مدیریت اشکال زدا در ACCESSCTRL بستگی دارد، در حالی که کنترل هسته ایمن ممکن است حتی زمانی که خواندن مستقیم رد شود، امکان استخراج با واسطه هسته را فراهم کند. این تحلیل معماری است، نه یک نتیجه بوت رمزگذاری شده آزمایش شده. بوت رمزگذاری شده همچنان از فلاش خارجی در برابر بازرسی آفلاین محافظت می کند.

توالی نشان‌داده‌شده دسترسی به حافظه منتسب به ایمن، کنترل اجرای دنیای امن، و دسترسی به رمز چالش را پس از تنظیم مجدد قفل صفحه زمان اجرا، فراهم می‌کند. به منابع زیر نیاز دارد:

RP2350 پرچم‌های حیاتی برای غیرفعال کردن اشکال‌زدایی را در OTP با رای اضافی رمزگذاری می‌کند، اما DEBUGEN می‌تواند اثر آن‌ها را لغو کند و هیچ حفاظتی معادل مستند در برگه داده ندارد. در آزمایش‌های ما، پالس‌های لیزر DEBUGEN را علی‌رغم DEBUGEN_LOCK تغییر دادند و می‌توانستند بیت قفلی را تنظیم کنند که از بازگرداندن مقدار غیرفعال شده میان‌افزار جلوگیری کند. به طور جداگانه، بازنشانی نجات RP-AP قفل صفحه زمان اجرا چالش را به مقدار ثابت آن بازگرداند و در عین حال از اجرای سفت‌افزار کاربر جلوگیری کرد.

مکانیسم‌های قابل مشاهده نرم‌افزار هر کدام عملکرد مستند خود را انجام می‌دهند، اما تعامل آنها با خطای لیزر، اشکال‌زدایی ایمن و بازیابی راز چالش را فعال می‌کند. PEM دیفرانسیل ابتدا فعالیت DEBUGEN وابسته به بیت را جدا کرد و LFI هدایت شده آن سرنخ فضایی را به اشکال زدایی امن پایدار تبدیل کرد. درس سطح سیستم این است که تجزیه و تحلیل امنیتی باید مسیر اجرای کامل را پوشش دهد، از پیکربندی مداوم OTP تا ثبات های کنترل قابل تغییر و رفتار بازنشانی، زیرا امنیت سیستم به آن مسیر بستگی دارد نه به مکانیسم های جداگانه.

ما این عیب را در 28 ژوئیه 2026 به Raspberry Pi فاش کردیم. از تیم Raspberry Pi برای مشارکت در بحث‌های افشاگری و رویکرد شفاف آنها در تحقیقات امنیتی تشکر می‌کنیم.

آنتوان پلین، کارآموز امنیت سخت افزار در Ledger Donjon

https://github.com/raspberrypi/rp2350_hacking_challenge مخزن RP2350 Hacking Challenge، حاوی پیکربندی قفل مرجع و سیستم عاملی است که ما تکرار کردیم. ↩

کورک، تزریق خطای لیزر با بودجه: نسخه RP2350. ↩

بررسی نجات مرحله 1 از مسیر بوت هسته 0 در src/main/arm/varm_boot_path.c است. در src/main/arm/arm8_bootrom_rt0.S، varm_wait_rescue وارد حلقه WFI با وقفه varm_dead_quiet می شود در حالی که هسته 1 در مسیر انتظار برای برداری رام بوت باقی می ماند. ↩