gamozolabs/applepieهايبرفايزر للتجريب بالبيانات العشوائية مبني باستخدام WHVP و Bochs
مرحباً! أهلاً بك في applepie! هذه أداة مصممة للتجريب (fuzzing) والتفحص الداخلي واكتشاف الأخطاء! هذا هايبرفايزر يستخدم واجهة برمجة تطبيقات منصة هايبرفايزر ويندوز (Windows Hypervisor Platform API) الموجودة في الإصدارات الحديثة من ويندوز (تم تطويره واختباره تحديداً على ويندوز 10 build 17763). يُستخدم Bochs لتوفير تفحص داخلي عميق ومحاكاة الأجهزة.
واجهة برمجة تطبيقات منصة هايبرفايزر ويندوز (WHVP) هي مجموعة واجهات برمجية للوصول إلى قدرات هايبرفايزر Hyper-V. تسهل هذه الواجهة علينا تنفيذ جهاز افتراضي بالكامل في مساحة المستخدم دون الحاجة إلى أي برامج تشغيل أو أذونات خاصة.
هذا مشروع قيد التطوير السريع. سأغرد غالباً عند إصدار ميزات جديدة قبل توثيقها.
أحب أن يكون لمشاريعي أشياء مادية:
هذه أداة مصممة للتجريب (fuzzing) والتفحص الداخلي أثناء البحث الأمني. باستخدام هايبرفايزر، يمكن تطبيق تقنيات التجريب الشائعة على أي هدف، سواء كان في النواة أو مساحة المستخدم. تسمح هذه البيئة بتجريب أنظمة كاملة دون الحاجة إلى شفرة المصدر للهدف. على مستوى الهايبرفايزر، يمكن جمع تغطية الكود، وعند الحاجة يمكن استخدام محاكاة Bochs لتوفير تفحص داخلي تعسفي في بيئة محاكاة. يمكن استخدام معلومات التغطية هذه لمعرفة فعالية حالات التجريب. يمكن حفظ حالة التجريب التي تسببت في زيادة التغطية كونها حالة مثيرة للاهتمام. يمكن استخدام هذا المدخل لاحقاً، والبناء عليه بإفسادات جديدة.
التجريب باللقطات (Snapshot fuzzing) هو الاستخدام الأساسي لهذه الأداة. حيث تلتقط لقطة للنظام في حالة معينة، وتحفظها. يمكن بعد ذلك تحميل هذه اللقطة للتجريب، حيث يتم حقن حالة تجريب، ثم استئناف التنفيذ. نظراً لأنه يمكن إعادة تعيين الجهاز الافتراضي بتكلفة منخفضة جداً، يمكن إعادة تعيينه بشكل متكرر. إذا استغرق Word 5 ثوانٍ للإقلاع، ولكن يمكنك التقاط لقطة لحظة قراءته لملفك، يمكنك تقصير حالة التجريب إلى ما هو ذو صلة بالمدخل فقط. هذا يسمح بحلقة تجريب ضيقة جداً دون الحاجة إلى الوصول إلى شفرة المصدر. نظراً لأن الأجهزة الافتراضية هي أنظمة منفصلة تماماً، يمكن تشغيل العديد منها بالتوازي للسماح بالتوسع إلى جميع النوى.
حالياً تدعم هذه الأداة فقط جمع تغطية الكود، وتنزيل الرموز الديناميكية لويندوز، وتحليل الرموز/الوحدات لأهداف ويندوز أيضاً. إضافة دعم التجريب سيكون قريباً جداً.
نظراً لأنني كتبت تقريباً جميع الميزات هنا من قبل (التغطية، التجريب، إعادة التعيين السريع، إلخ). أتوقع أن يصبح هذا المشروع جاهزاً للتجريب بسرعة كبيرة، إلا إذا تشتت انتباهي :D
أهدف إلى نهاية يناير للتغطية (تم!)، والملاحظات، وعرض الوحدات (تم!)، وقوائم العمليات، وإعادة التعيين السريع، ودعم الرموز (تم!). مما سيجعله أداة تجريب قوية جداً.
الهدف الرئيسي المدعوم هو ويندوز 10 الحديث. الأهداف التي تعمل بنظام ويندوز تدعم تنزيل الرموز من مخزن الرموز. هذا يسمح بتغطية رمزية لأهداف ويندوز مباشرة. ومع ذلك، الكود مكتوب بطريقة يمكن بسهولة إضافة التنوير (enlightenment) لأنظمة لينكس.
بدون أي تنوير، يمكن تجريب أي نظام تشغيل يمكنه الإقلاع وجمع تغطية أساسية.
قبل الإبلاغ عن مشكلات دعم نظام التشغيل، يرجى التحقق من أن المشكلة في الهايبرفايزر/التغييرات على Bochs عن طريق محاولة إقلاع هدفك باستخدام Bochs القياسي المُعد مسبقاً دون هايبرفايزر. Bochs ليس شائع الاستخدام وغالباً ما يحتوي على أخطاء مدمرة حتى للأشياء الشائعة مثل إقلاع لينكس. خاصة مع التغييرات الداخلية السريعة في استخدام CPUID/MSR مع تخفيفات Spectre/Meltdown التي تدخل في أنظمة التشغيل.
انظر صفحة المشكلات على Github للحصول على قائمة بالمشكلات. لقد بدأت بها بالفعل ببعضها. بعض هذه المشكلات تحتاج إلى معالجة سريعة قبل بدء تطوير التجريب.
لبناء هذا تحتاج إلى بعض الأشياء:
قم بتثبيت Visual Studio 2017 وتأكد من تحديثه. نحن نستخدم واجهات برمجة تطبيقات ورؤوس ومكتبات متطورة جداً.
كنت أستخدم إصدار cl.exe: Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
وإصدار SDK 10.0.17763.0
قم بتثبيت Rust عبر https://rustup.rs/. استخدمت rustc 1.32.0-nightly (b3af09205 2018-12-04)
تأكد من تثبيت سلسلة الأدوات x86_64-pc-windows-msvc حيث أن 64 بت فقط مدعومة لهذا المشروع.
تأكد من أن cargo موجود في مسار PATH. يجب أن يكون هذا هو الوضع الافتراضي.
اذهب واحصل على python https://www.python.org/ وتأكد من أنه في PATH الخاص بك بحيث يمكن استدعاء python.
قم بتثبيت Cygwin 64 بت (https://www.cygwin.com/setup-x86_64.exe) تحديداً إلى C:\cygwin64. عند تثبيت Cygwin تأكد من تثبيت حزمتي autoconf و make.
اذهب إلى "تشغيل ميزات ويندوز أو إيقاف تشغيلها" وحدد مربع الاختيار بجانب "Hyper-V" و "Windows Hypervisor Platform". يتطلب هذا بالطبع أن يدعم جهاز الكمبيوتر الخاص بك Hyper-V.
تم التحقق من دليل التثبيت هذا على ما يلي:
تثبيت نظيف لويندوز 10، build 17763
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64
Visual Studio Community 2017 الإصدار 15.9.4
applepie commit `f84c084feb487e2e7f31f9052a4ab0addd2c4cf9`
Python 3.7.2 x64
git version 2.20.1.windows.1
autoconf)make)git clone https://github.com/gamozolabs/applepiepython build.py
قد تستغرق عملية البناء الأولية هذه حوالي دقيقتين، على جهاز حديث من المحتمل أن تكون 20-30 ثانية.
فقط قم بتشغيل python build.py من الدليل الجذر لهذا المشروع. يجب أن يتحقق من سلامة البيئة وكل شيء يجب أن "يعمل فقط".
قم بتشغيل python build.py clean لتنظيف ثنائيات Bochs و Rust.
قم بتشغيل python build.py deepclean لإزالة جميع ثنائيات Bochs و Rust تماماً، كما يزيل جميع التهيئة لـ Bochs. استخدم هذا إذا قمت بإعادة تكوين Bochs بطريقة ما.
اقرأ عن تهيئة Bochs لمعرفة كيفية إعداد بيئتك. لدينا بعض المتطلبات، مثل sync=none، ips=1000000، ودعم معالج واحد حالياً فقط. يتم فرض هذه داخل الكود نفسه للتأكد من أنك لا تؤذي نفسك.
استخدم التهيئات المضمنة bochservisor_test\bochsrc.bxrc و bochservisor_test_real\bochsrc.bxrc كأمثلة. bochservisor_test_real هو على الأرجح أحدث تهيئة يجب أن تنظر إليها كمرجع.
الأهداف التي تعمل بنظام ويندوز تحتوي على تنوير بقائمة الوحدات النمطية، مما يسمح لنا برؤية قوائم جميع الوحدات في السياق الذي نعمل فيه. بهذا يمكننا تحويل عناوين التعليمات إلى وحدة + إزاحة. يساعد هذا الوحدة + الإزاحة في الحفاظ على معلومات التغطية بين حالات التجريب حيث تتغير حالة ASLR. كما يسمح بتلوين الوحدة في أداة مثل IDA لرؤية الكود الذي تم الوصول إليه بصرياً.
بالنسبة لأهداف ويندوز، سيتم تنزيل الرموز ديناميكياً من مخزن الرموز باستخدام _NT_SYMBOL_PATH الخاص بك واستخدام symchk. بدون وجود symchk في المسار، سيفشل بصمت. مع الرموز، يمكن حفظ نسخة مقروءة للتغطية لعرضها. علاوة على ذلك، مع الرموز الخاصة يمكن تحويل التغطية إلى مصدر:سطر بحيث يمكن تلوين شفرة المصدر.
حسناً، لا توجد اختبارات حقاً، ولكن يوجد bochservisor_test وهو نظام تشغيل صغير يتحقق فقط من أن كل شيء يقلع مع الهايبرفايزر.
هناك ثم bochservisor_test_real وهو تهيئة أستخدمها لأشياء مثل ويندوز/لينكس. هذا هو الذي سيتم تحديثه غالباً بشكل متكرر.
تقدم قاعدة الكود هذه كمية صغيرة من الكود إلى Bochs للسماح بالوصول المعياري إلى سياق وحدة المعالجة المركزية، والذاكرة الخلفية من الفعلية للضيف، وتقديم حالة الجهاز ووحدة المعالجة المركزية خطوة بخطوة.
الكود الرئيسي الذي تريد النظر إليه موجود في lib.rs في مشروع Rust bochservisor.
في حلقة وحدة المعالجة المركزية الرئيسية لـ Bochs، نقوم بدلاً من ذلك بـ LoadLibrary() لتحميل DLL bochservisor. يقوم هذا DLL بتصدير روتين واحد وهو حلقة Rust لوحدة المعالجة المركزية التي سيتم استدعاؤها.
سيمرر Bochs بنية إلى هذا الروتين bochs_cpu_loop والتي ستحتوي على مؤشرات دالة للحصول على معلومات من Bochs وتقديم حالة الجهاز ووحدة المعالجة المركزية خطوة بخطوة فيه.
عند حدوث MMIO أو I / O، سيخرج الهايبرفايزر مع خطأ في الذاكرة أو خطأ في تعليمات I / O. بينما توفر WHVP واجهة برمجة تطبيقات للمحاكاة، إلا أنها ناقصة حقاً وغير كافية.
بدلاً من ذلك نستخدم Bochs الموجود بالفعل ونقدم بضع تعليمات. من خلال الحفاظ على مزامنة حالة وحدة المعالجة المركزية للهايبرفايزر مع Bochs يمكننا التبديل ديناميكياً بين الهايبرفايزر والمحاكاة في أي وقت (أو على الأقل يجب أن نكون قادرين على ذلك).
هذا يعني أن حالة الهايبرفايزر الكاملة تكون دائماً متزامنة مع Bochs وبالتالي يجب أن تعمل لقطات Bochs كالمعتاد ويمكن إقلاعها بدون الهايبرفايزر (ربما باستثناء بعض حالة CPUID التي تحتاج إلى تخزين في معلومات اللقطة).
عند حدوث MMIO أو I / O، نقوم بتشغيل عدد معين من التعليمات تحت المحاكاة بدلاً من محاكاة واحدة فقط. نظراً لتكاليف واجهة برمجة التطبيقات للدخول والخروج من الهايبرفايزر، واحتمال أن تحدث عمليات MMIO مماثلة بجانب بعضها البعض، نقوم بتقديم بضع تعليمات. هذا يسمح لنا بتقليل الحمل الزائد لواجهة برمجة التطبيقات وتقليل تردد VMEXIT. هذا رقم قابل للضبط ولكن ما هو موجود في قاعدة الكود من المحتمل أن يكون هناك لسبب.
نتعامل مع المقاطعات بطريقة مثيرة للاهتمام حقاً. بدلاً من جدولة المقاطعات ليتم تسليمها إلى الهايبرفايزر، نتعامل مع جميع المقاطعات في محاكاة Bochs نفسها. أشياء مثل الاستثناءات التي تحدث داخل الهايبرفايزر بالطبع لا يتم التعامل معها بواسطة Bochs.
هذا يعطينا أيضاً ميزات لا تدعمها WHVP، مثل SMIs (لـ SMM). يستخدم BIOS الخاص بـ Bochs SMM افتراضياً وبدون دعم SMI يجب بناء BIOS مخصص. لقد قمت بذلك في التكرار الأول لهذا... لا أوصي به.
هذا المشروع مصمم للتجريب، ولكنه جديد جداً (فقط بضعة أيام) بحيث لا يحتوي على أي من هذه الميزات.
بعض الأشياء الأولى التي ستأتي ستكون:
يمكننا نظرياً تشغيل أجهزة Bochs في خيط واحد في حلقة في الوقت الفعلي، وخيط آخر لتشغيل الهايبرفايزر. سيتم التواصل في الأحداث غير المتزامنة عبر IPC وستسمح بتحديث الأجهزة أثناء التنفيذ في الضيف.
حالياً كل شيء يحدث في خيط واحد مما يعني أن الهايبرفايزر يجب أن يخرج على فاصل زمني للتأكد من أننا نستطيع تقديم الأجهزة. يبدو الأمر كما لو أننا كتبنا جدولة خاصة بنا.
قد يكون هذا أسرع قليلاً، لكنه يزيد من التعقيد ويضيف احتمالية لمشاكل السباق. من الصعب القول ما إذا كان هذا سيحدث أبداً.
لست متأكداً من الطريقة التي سأستخدمها لجمع تغطية الكود، ولكن سيكون هناك على الأقل بعض الخيارات. تتراوح من الدقيقة إلى السريعة، إلخ. ستكون جميع آليات التغطية هذه على مستوى النظام ولن تتطلب مصدر أو رموز الأهداف.
تحليل هياكل نظام التشغيل للحصول على معلومات بدائية مثل قوائم العمليات، قوائم الوحدات النمطية، إلخ. سيتم استخدام هذا بعد ذلك للاستعلام عن PDBs للحصول على معلومات الرموز.
الإبلاغ عن الأعطال بطريقة مفيدة. من الناحية المثالية، ستكون التفريغات المصغرة (minidumps) جيدة حيث يمكن تحميلها ومعالجتها في WinDbg. قد يكون هذا سهلاً نسبياً لأن DMPs هي مجرد ذاكرة فعلية وسياق معالج، وهو ما لدينا بالفعل.
لدي بعض التقنيات الممتعة لتحديد السبب الجذري للأخطاء والتي كانت ناجحة تاريخياً. أخطط لجلبها هنا.
من خلال تتبع الصفحات المتسخة واستعادة الأشياء المعدلة فقط، يجب أن نكون قادرين على إعادة تعيين الأجهزة الافتراضية بسرعة كبيرة. هذا يعطينا القدرة على التجريب بأقصى سرعات على جميع نوى نظام الهدف. هذا مشابه لما فعلته في falkervisor لذلك تم التفكير فيه وتصميمه بالفعل. يحتاج فقط إلى نقله هنا.
تجريب سريع جداً يلغي التنفيذ عند حدوث MMIO أو I / O. هذا يسمح بقضاء كل وقت وحدة المعالجة المركزية في الهايبرفايزر وبدون وقت محاكاة. هذا له جانب سلبي يتمثل في عدم دعم أشياء مثل الإدخال/الإخراج للقرص أثناء حالة التجريب، ولكنه لطيف.
بعض المفاهيم الأساسية لهذا المشروع هي الحد الأدنى المطلق من التعديلات على Bochs. هذا يسمح لنا بالحفاظ على تحديث جزء Bochs من هذا المستودع.
الهدف هو أيضاً نقل أكبر قدر ممكن من الكود إلى Rust و dlls لجعل النظام أكثر نمطية وأماناً. هذا سيقلل من احتمالية حدوث أخطاء تلف سخيفة في الهايبرفايزر نفسه، مما يسبب نتائج تجريب غير صالحة.
حالياً الهايبرفايزر هو DLL ويمكن استبداله دون تغييرات في Bochs (إلا إذا تغيرت واجهة FFI).
يجب توثيق التغييرات الإضافية على Bochs نفسها بوضوح، وسأقوم بإعداد مستند لذلك قريباً لتتبع التغييرات على Bochs التي يجب نقلها وإعادة تقييمها مع تحديثات Bochs.