ثغرة في قلب iOS: كيف تحوّل خطأ صغير في AppleKeyStore إلى نافذة على ذاكرة النواة؟

في أنظمة مثل iOS، لا تصل التطبيقات إلى النواة مباشرة، ولا يُفترض أن تتمكن من التعامل بحرية مع الخدمات الحساسة التي تدير المفاتيح والهوية والتشفير. هناك طبقات متعددة من الحماية: sandbox، صلاحيات entitlements، خدمات وسيطة، وعزل بين التطبيقات والمكونات منخفضة المستوى.

لكن أحيانًا لا يحتاج المهاجم إلى كسر كل هذه الحواجز دفعة واحدة.

يكفي أن يجد مسارًا شرعيًا يسمح للتطبيق بتمرير بيانات إلى مكوّن حساس، ثم يكتشف أن هذا المكوّن يثق في قيمة كان يجب أن يتحقق منها.

هذا تقريبًا هو جوهر CVE-2026-65343.

الثغرة تقع داخل AppleKeyStore، أحد المكونات الحساسة في منظومة Apple، وتحديدًا في مسار مسؤول عن معالجة رسائل مرتبطة بـSecure Enclave وACM. المشكلة الأساسية بسيطة من حيث المبدأ: يوجد طول بيانات معلن داخل رسالة، لكن الكود لا يتأكد من أن هذا الطول يتوافق فعلًا مع المساحة المتبقية في الرسالة.

النتيجة؟

يمكن للنواة أن تقرأ بيانات بعد نهاية المخزن المتوقع، ثم تعيد جزءًا من هذه البيانات إلى مساحة المستخدم.

وفي عالم استغلال النواة، تسريب مؤشر واحد صالح قد يكون كافيًا لكشف مكان تحميل النواة في الذاكرة، وبالتالي إضعاف أو تجاوز حماية مثل KASLR.

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

#قبل التفاصيل: لماذا تعتبر هذه الثغرة مهمة؟

لفهم أهمية المشكلة، نحتاج إلى النظر إليها كجزء من سلسلة حماية متكاملة.

عندما يعمل تطبيق على iPhone، لا يفترض أن يعرف أين توجد النواة في الذاكرة. حتى لو احتوى النظام على ثغرة أخرى تسمح بالكتابة أو تنفيذ تعليمات، فإن معرفة عناوين النواة تبقى مشكلة بسبب KASLR.

KASLR اختصار لـ:

Kernel Address Space Layout Randomization

وفكرته أن النظام يغيّر موقع تحميل النواة ومكوناتها عند الإقلاع.

بصيغة مبسطة:

بدل أن يعرف المهاجم أن دالة حساسة موجودة دائمًا عند:

0xfffffff007123456

قد تصبح في كل تشغيل عند عنوان مختلف.

لكن إذا استطاع المهاجم تسريب مؤشر حقيقي من ذاكرة النواة، يمكنه أحيانًا استخدام هذا المؤشر لحساب مقدار الإزاحة العشوائية، أو ما يسمى:

KASLR slide

وهنا تتحول الذاكرة من مساحة مجهولة نسبيًا إلى خريطة يمكن الاستدلال عليها.

#أين تقع الثغرة؟

تقع المشكلة في امتداد النواة:

AppleKeyStore

وفي المسار:

_LibSer_SEPControl_Deserialize

هذا المسار يتعامل مع رسائل تحكم مرتبطة بـSEP وACM.

ولتبسيط المصطلحات:

• SEP هو اختصار لـSecure Enclave Processor، وهو الجزء المخصص لحماية العمليات الحساسة المرتبطة بالمفاتيح والهوية.
• ACM يشير إلى Credential Manager، وهو جزء من سلسلة إدارة عمليات المصادقة والاعتماد.
• AppleKeyStore هو مكوّن منخفض المستوى يتعامل مع مفاتيح النظام وبعض العمليات المرتبطة بها.

المشكلة تظهر عندما تقوم الدالة بفك أو إلغاء تسلسل رسالة تحتوي على مؤشر إلى بيانات وطول معلن لهذه البيانات.

من المفترض منطقيًا أن يتحقق النظام من الشرط التالي:

declared_length <= (acm_msg_end - payload_ptr)

أي:

هل الطول المطلوب نسخه أصغر من أو يساوي عدد البايتات المتبقية فعلًا داخل الرسالة؟

لكن في المسار المتأثر لا يحدث هذا التحقق بالشكل المطلوب.

#مثال بسيط لفهم الخطأ

تخيل أن لديك صندوقًا يحتوي على 24 بايت من البيانات.

لكن يوجد داخل الصندوق حقل يقول:

length = 2048 bytes

إذا وثق البرنامج بهذا الرقم مباشرة، فقد يحاول قراءة 2048 بايت، رغم أن البيانات الحقيقية لا تتجاوز 24 بايت.

المشكلة ليست في أول 24 بايت.

المشكلة في كل ما سيُقرأ بعدها.

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

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

Kernel pointers
Object addresses
Function-related addresses
Internal metadata

وهنا تتحول مشكلة حدود بسيطة إلى تسريب معلومات حساس.

#القيمة التي تفتح الباب: 0x800

في السيناريو الموضح في إثبات المفهوم، يتم تمرير:

declared_length = 0x800

والقيمة:

0x800

تعادل:

2048 bytes

بينما لا تكون كمية البيانات الفعلية المتبقية بهذا الحجم.

نتيجة ذلك، يستمر مسار النسخ في قراءة ما يقارب:

0x7E8 bytes

بعد نهاية مخزن رسالة ACM.

يمكن تمثيل الفكرة هكذا:

+----------------------+------------------------------+
| ACM Message          | Adjacent Kernel Memory       |
+----------------------+------------------------------+
| Valid Payload        | Objects / pointers / metadata|
+----------------------+------------------------------+
        ^
        |
    payload_ptr

Declared length:
0x800 bytes  ------------------------------------------>

لو كان الحد الصحيح للرسالة هنا مثلًا 24 بايت فقط، فإن بقية القراءة ستتجاوز المخزن الأصلي وتدخل في ذاكرة مجاورة.

هذه هي قراءة خارج الحدود:

Out-of-Bounds Read

#كيف تبدو المشكلة داخل الكود؟

يبسط المسار المتأثر بالشكل التالي:

ldr  w2, [acm_msg + declared_length_offset]
; missing bounds validation
bl   copyout

القيمة الموجودة في:

w2

تُستخدم كطول للنسخ.

المشكلة ليست في copyout() نفسها، بل في أن القيمة التي تصل إليها لم يتم التحقق منها أولًا مقابل الحجم الفعلي المتبقي في الرسالة.

السلوك الآمن يجب أن يكون أقرب إلى:

remaining = acm_msg_end - payload_ptr;

if (declared_length > remaining) {
    return ERROR;
}

copyout(payload_ptr, user_buffer, declared_length);

أما في الحالة المتأثرة، فغياب هذا الشرط يسمح للقراءة بأن تمتد خارج الحدود المنطقية للرسالة.

#لماذا نحتاج أصلًا إلى AppleKeyStore؟

هنا تبدأ الجزئية الأكثر إثارة للاهتمام في السلسلة.

تطبيق sideloaded لا يستطيع ببساطة تنفيذ:

IOServiceOpen("AppleKeyStore")

والحصول على جلسة مباشرة.

السبب هو:

sandbox

أي أن أحد الحواجز الأمنية يعمل بالفعل.

لكن وجود حاجز على المسار المباشر لا يعني بالضرورة أن كل المسارات غير المباشرة مغلقة.

وهذا هو الفرق المهم في هذه الثغرة.

#المسار غير المباشر عبر Secure Enclave

بدل محاولة فتح AppleKeyStore مباشرة، يستفيد إثبات المفهوم من مسار شرعي داخل:

Security.framework

الفكرة تكون كالتالي:

1. ينشئ التطبيق مفتاحًا داخل Secure Enclave.
2. يطلب من النظام توقيع رسالة باستخدام المفتاح.
3. أثناء تنفيذ العملية، قد تقوم Security.framework باستدعاء IOKit داخل العملية نفسها.
4. إذا حدث ذلك، يمكن اعتراض الاستدعاء والتقاط جلسة ACM حقيقية.
5. بعدها يمكن إعادة استخدام المقبض في الرسالة التي تستهدف المسار المتأثر.

أي أن التطبيق لا يقول للنظام:

Give me direct AppleKeyStore access

بل يقول:

Please sign this message using my Secure Enclave key

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

#إنشاء مفتاح داخل Secure Enclave

يعتمد السيناريو على إنشاء مفتاح:

P-256

داخل:

Secure Enclave

باستخدام:

SecKeyCreateRandomKey

مع الخاصية:

kSecAttrTokenIDSecureEnclave

ثم يتم توقيع رسالة باستخدام:

SecKeyCreateSignature()

والخوارزمية:

kSecKeyAlgorithmECDSASignatureMessageX962SHA256

الهدف الأساسي هنا ليس التوقيع نفسه.

التوقيع مجرد عملية شرعية تُجبر النظام على المرور بالمسارات الداخلية المطلوبة.

وهذا مثال مهم في تحليل الثغرات:

أحيانًا تكون الوظيفة الشرعية نفسها هي البوابة للوصول إلى المكوّن الحساس.

#لماذا DYLD_INTERPOSE؟

حتى الآن نحتاج إلى التقاط الاستدعاء:

IOConnectCallMethod

الذي قد تنفذه Security.framework.

أحد الأساليب المعروفة لاعتراض الدوال في بيئة Apple هو:

fishhook

لكن في الإصدارات الحديثة توجد مشكلة.

جدول:

GOT

قد يكون موجودًا داخل:

__DATA_CONST

وبعد اكتمال التحميل تصبح الصفحات:

Read Only

لذلك محاولة تغيير المؤشر أثناء التشغيل قد تؤدي إلى:

KERN_PROTECTION_FAILURE

ومن ثم:

SIGBUS

ولهذا يستخدم السيناريو:

DYLD_INTERPOSE

بدل تعديل جدول الربط أثناء التشغيل.

#كيف يعمل DYLD_INTERPOSE بصورة مبسطة؟

الفكرة أن التطبيق يضيف جدول اعتراض في:

__DATA,__interpose

ويخبر محمل Apple:

dyld

أن يستبدل دالة معينة بدالة أخرى عند تحميل الصورة.

يمكن تصورها هكذا:

Security.framework
        |
        v
IOConnectCallMethod
        |
        v
[Interposed wrapper]
        |
        +----> Capture conn + handle
        |
        v
Original IOConnectCallMethod

أي أن الاعتراض لا يمنع العملية الأصلية.

هو يراقبها، يلتقط ما يحتاجه، ثم يعيد تمرير الاستدعاء إلى الدالة الحقيقية.

#ما الذي يتم التقاطه؟

عندما يمر استدعاء مناسب، يتم التقاط:

conn

ومقبض:

handle[16]

يمثل جلسة ACM حقيقية.

ويتم فحص أول:

16 bytes

من:

structin

للبحث عن المقبض.

إذا كان غير صفري، يتم حفظه لاستخدامه لاحقًا.

بعد ذلك يمكن بناء رسالة مصممة خصيصًا للمسار المتأثر.

#شكل رسالة الاختبار

الرسالة المستخدمة في إثبات المفهوم يبلغ حجمها:

28 bytes

وتتكون تقريبًا من:

شكل مبسط للرسالة:

Offset 0x00
+-----------------------------------+
| ACMHandle (16 bytes)              |
+-----------------------------------+
| cmd_type = 0                      |
+-----------------------------------+
| cmd_size = 0                      |
+-----------------------------------+
| declared_length = 0x800           |
+-----------------------------------+
Offset 0x1C

الحقل الأخير هو المفتاح.

لأن 0x800 لا يمثل الحجم الحقيقي المتبقي في الرسالة.

#كيف يظهر التسريب؟

قبل إرسال الرسالة، يجهز إثبات المفهوم مخزن إخراج بحجم:

0x2000

أي:

8192 bytes

ثم يملؤه بقيمة ثابتة:

0xBB

مثلًا:

BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB...

بعد تنفيذ الاستدعاء، يتم فحص المخزن.

إذا تغيرت أجزاء منه، فهذا يعني أن النظام كتب بيانات حقيقية في المخرجات.

بعد ذلك تتم قراءة البيانات على دفعات:

8 bytes

والبحث عن قيم تشبه مؤشرات نواة.

من الأنماط المستخدمة:

0xfffffff0xxxxxxxx

مثلًا، لو ظهر شيء مشابه لـ:

0xfffffff012345678

فهذا ليس دليلًا نهائيًا وحده، لكنه قيمة مرشحة لأن تكون مؤشرًا داخل فضاء عناوين النواة.

#لماذا البحث عن Kernel Pointer مهم؟

لو عرف الباحث أن مؤشرًا معينًا يشير إلى كائن أو رمز ذي إزاحة ثابتة داخل النواة، يمكنه استخدامه لحساب:

KASLR slide

الفكرة الرياضية بسيطة.

لدينا قاعدة ثابتة معروفة من صورة النواة:

KERN_BASE_STATIC

ولدينا إزاحة رمز معروفة:

known_off

إذن العنوان المتوقع من دون KASLR هو:

KERN_BASE_STATIC + known_off

إذا حصلنا على عنوان حقيقي مسرب:

leaked_pointer

يمكن حساب الإزاحة:

slide = leaked_pointer - (KERN_BASE_STATIC + known_off)

وفي إثبات المفهوم:

KERN_BASE_STATIC = 0xfffffff007004000
known_off        = 0x18d8774

#مثال رقمي مبسط

نفترض لأغراض الشرح فقط أن:

Static symbol address = 0x10000000

لكن المؤشر المسرب من الجهاز هو:

0x12000000

إذن:

slide = 0x12000000 - 0x10000000

فتكون النتيجة:

slide = 0x02000000

بعد معرفة هذه الإزاحة، يصبح بالإمكان تطبيقها على عناوين ثابتة أخرى داخل صورة النواة للوصول إلى عناوينها الفعلية أثناء التشغيل.

هذا تحديدًا هو السبب الذي يجعل تسريب مؤشرات النواة ذا قيمة أمنية عالية، حتى لو لم يمنح بحد ذاته تنفيذ تعليمات.

#التحقق من أن المؤشر منطقي

لا يعتمد إثبات المفهوم على أي قيمة تبدأ بالشكل المطلوب فقط.

هناك تحقق إضافي يعتمد على آخر:

12 bits

من العنوان.

تتم مقارنة آخر 12 بت من المؤشر المسرب مع آخر 12 بت من:

KERN_BASE_STATIC + known_off

إذا تطابقت، تصبح القيمة أكثر ترجيحًا لأن تكون مرتبطة بالرمز المتوقع.

هذا لا يحول التخمين إلى برهان مطلق، لكنه يقلل احتمالات التعامل مع قيمة عشوائية باعتبارها مؤشرًا صالحًا.

#لماذا يعاد الاختبار على 163 selector؟

إثبات المفهوم لا يعتمد على استدعاء واحد فقط.

بل يعيد المحاولة عبر:

163

من مؤشرات أو محددات AKS، من:

1

إلى:

163

ويفحص النتائج بحثًا عن تسريب مناسب.

عند العثور على مؤشر، يظهر ناتج مشابه:

KPTR @+XXXX = 0xfffffff0YYYYYYYY

هذه الخطوة تزيد فرص المرور بمسار يعيد بيانات تحتوي على تخصيصات مجاورة مفيدة.

#ماذا لو لم يتم التقاط جلسة ACM؟

هذه نقطة مهمة لأن نجاح السلسلة ليس مضمونًا على كل جهاز.

في بعض الأجهزة أو البنى، قد لا تنفذ Security.framework عملية التوقيع مباشرة داخل التطبيق.

بدل ذلك قد ترسل الطلب إلى:

secd

عن طريق:

XPC

في هذه الحالة يصبح المسار:

App
 |
 | XPC
 v
secd
 |
 v
AppleKeyStore

بدل:

App
 |
 v
Security.framework
 |
 v
IOConnectCallMethod
 |
 v
AppleKeyStore

الفرق كبير.

في الحالة الأولى، استدعاء IOConnectCallMethod الحقيقي يحدث في عملية أخرى.

وبالتالي:

DYLD_INTERPOSE

الموجود داخل التطبيق لن يراه.

ولا يتم التقاط جلسة ACM.

#المسار الاحتياطي

إذا فشل التقاط المقبض، يحاول إثبات المفهوم مسارًا احتياطيًا يعتمد على:

zero handle

ومحاولة فتح:

AppleKeyStore

مباشرة.

لكن هذا المسار غالبًا ما يصطدم بحماية:

sandbox

وحتى إذا وصل الاختبار إلى المسار المتأثر، فإن عدم امتلاك جلسة ACM صحيحة يعني أن النتيجة لا تعادل السلسلة الكاملة.

بمعنى آخر:

Reach vulnerable path

لا يساوي بالضرورة:

Leak usable kernel pointer

ولا يساوي:

Defeat KASLR

هذه مستويات مختلفة من إثبات الأثر.

#سلسلة الثغرة بصورة كاملة

يمكن تلخيص السلسلة المنطقية هكذا:

Sideloaded App
      |
      v
Create Secure Enclave Key
      |
      v
SecKeyCreateSignature()
      |
      v
Security.framework
      |
      v
IOConnectCallMethod
      |
      +----> DYLD_INTERPOSE captures ACM session
      |
      v
Reusable conn + handle
      |
      v
Craft ACM message
      |
      v
declared_length = 0x800
      |
      v
AppleKeyStore
      |
      v
_LibSer_SEPControl_Deserialize
      |
      v
Missing bounds validation
      |
      v
copyout() reads beyond ACM buffer
      |
      v
Kernel memory disclosure
      |
      v
Kernel pointer candidate
      |
      v
KASLR slide calculation

بهذا الشكل يصبح من السهل رؤية أن الثغرة ليست "خطأ واحدًا يعطي كل شيء"، بل سلسلة من الشروط والمسارات التي يجب أن تتصل ببعضها.

#التأثير الحقيقي للثغرة

من المهم جدًا عدم تضخيم الأثر.

المادة المتاحة تثبت:

Out-of-Bounds Read

وتوضح إمكانية:

Kernel pointer disclosure

وفي الظروف المناسبة:

KASLR defeat

لكنها لا تثبت وحدها:

Remote Code Execution

ولا:

Sandbox Escape

ولا:

Kernel Code Execution

ولا:

Privilege Escalation

الفرق مهم.

لأن تسريب عنوان النواة غالبًا ما يكون مرحلة مساعدة داخل سلسلة استغلال أكبر، وليس بالضرورة الثغرة النهائية التي تمنح السيطرة على الجهاز.

#لماذا تعتبر هزيمة KASLR خطوة خطرة رغم ذلك؟

في الاستغلال الحديث، كثير من الثغرات لا تعمل منفردة.

قد يمتلك المهاجم مثلًا:

Bug A = Kernel memory disclosure
Bug B = Kernel write primitive
Bug C = Sandbox escape

كل واحدة منها بمفردها قد تكون محدودة.

لكن عند جمعها:

Bug A + Bug B + Bug C

يمكن أن تتحول إلى سلسلة استغلال كاملة.

لذلك فإن ثغرة تسريب معلومات من النواة لها قيمة كبيرة للمهاجمين، لأنها قد تكسر أحد الافتراضات الأساسية التي تعتمد عليها الثغرات الأخرى:

The attacker does not know kernel addresses

#ما الذي يجعل هذه الحالة مثيرة من منظور هندسة الأمان؟

هناك ثلاثة دروس تقنية مهمة في هذه الثغرة.

أولًا، الحماية على الواجهة المباشرة ليست كافية دائمًا.

النظام يمنع التطبيق من فتح:

AppleKeyStore

مباشرة، لكن توجد واجهات شرعية أخرى قد تصل إلى نفس المكوّن داخليًا.

ثانيًا، حدود الثقة مهمة جدًا داخل عمليات إلغاء التسلسل.

أي قيمة مثل:

length
size
offset
count

قادمة من رسالة أو مخزن يجب التعامل معها على أنها غير موثوقة حتى تثبت صلاحيتها.

ثالثًا، عزل الصلاحيات لا يعوض أخطاء سلامة الذاكرة.

قد يكون التطبيق داخل:

sandbox

وبدون:

entitlements

لكن إذا سمح مكوّن نواتي لمسار شرعي بالوصول إلى عملية نسخ غير محمية، فقد تظهر قناة تسريب رغم القيود الأخرى.

#الفرق بين Reachability وExploitability

هذه الثغرة مثال جيد على ضرورة التمييز بين مفهومين:

Reachability

و:

Exploitability

Reachability تعني:

هل يستطيع المهاجم إيصال التنفيذ إلى الكود الضعيف؟

أما Exploitability فتعني:

هل يستطيع تحويل هذا الوصول إلى أثر أمني مستقر وقابل للاستخدام؟

في هذه الحالة، الوصول إلى المسار المتأثر وحده لا يكفي.

الحصول على:

real ACM handle

له دور حاسم في الوصول إلى النتيجة التي تسمح فعليًا بتسريب مؤشرات قابلة للاستخدام.

#النطاق المتأثر

وفق المادة المصدرية، تؤثر المشكلة في:

iOS 26.6 (23G71)

و:

iPadOS 26.6 (23G71)

والإصدارات الأقدم.

الإصدار الذي يحتوي على الإصلاح هو:

iOS 26.6.1 (23G83)

و:

iPadOS 26.6.1 (23G83)

وصدر الإصلاح بتاريخ:

2026-08-17

#الإصلاح

لا يذكر المصدر وجود:

Workaround

مستقل.

لذلك الإجراء الأساسي هو التحديث إلى الإصدار المصحح أو أحدث.

من منظور هندسي، الإصلاح المنطقي لمثل هذا النوع من المشاكل يجب أن يضمن أن أي عملية نسخ تعتمد على طول معلن تتحقق أولًا من:

payload_ptr + declared_length <= acm_msg_end

مع مراعاة حالات:

Integer overflow
Pointer overflow
Malformed offsets
Unexpected message sizes

المبدأ ببساطة:

لا تسمح لأي قيمة طول قادمة من رسالة أن تتحول مباشرة إلى طول لعملية نسخ قبل التحقق من حدود المخزن الفعلية.

#مؤشرات مرتبطة بإثبات المفهوم

لا تتضمن المادة عناوين:

IP addresses

ولا:

Domains

ولا:

File hashes

لكنها تذكر العناصر التالية:

File:
poc/poc_aks_oob.m

Keychain application tag:
com.research.poc.aksprobe

Service:
AppleKeyStore

Function:
_LibSer_SEPControl_Deserialize

Vulnerability:
CVE-2026-65343

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

#متطلبات إعادة التجربة المذكورة في المصدر

المتطلبات الأساسية تشمل جهازًا يعمل بإصدار متأثر مثل:

iOS 26.6 (23G71)

أو إصدار أقدم.

كما يعتمد السيناريو على الوصول إلى:

kSecAttrTokenIDSecureEnclave

وتشير المادة إلى أن السيناريو لا يتطلب تجاوز sandbox بحد ذاته.

لكن يجب الانتباه إلى أن نجاح التقاط جلسة ACM يعتمد على الجهاز وبنية النظام، لأن مسار توقيع المفتاح قد ينتقل عبر:

secd XPC

بدل التنفيذ داخل العملية.

#الخلاصة

CVE-2026-65343 ليست من نوع الثغرات التي يمكن اختصارها بعبارة "فتح التطبيق يؤدي إلى السيطرة على الجهاز".

قيمتها التقنية مختلفة.

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

المسار يبدأ من وظيفة شرعية جدًا:

Secure Enclave signing

ويمر عبر:

Security.framework

ثم يعتمد على التقاط جلسة:

ACM

وبعدها تصل الرسالة المصاغة إلى:

AppleKeyStore

حيث يسمح غياب التحقق من:

declared_length

بقراءة بيانات بعد نهاية المخزن.

إذا احتوت هذه البيانات على مؤشر صالح من النواة، يمكن استخدامه لحساب:

KASLR slide

وهذا هو جوهر الأثر الموثق.

المغزى الأعمق هنا ليس القيمة:

0x800

ولا حتى اسم الدالة المتأثرة.

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

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

#المصدر

• Apple Security Advisory — iOS 26.6.1