Skip to content
KitploitKITPLOIT
أدواتالمدونة
Log in
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
CVE-2020-0022 — مستودع بحثي يوثّق تجارب BlueFrag (CVE-2020-0022) المتعلقة بفيض كومة Bluetooth في Android، بما في ذلك تحليل انهيار GDB ومحاولات استغلال memcpy. | Kitploit
أدوات/GitHubGitHub/idkwim/cve-2020-0022
أمان أندرويدأمن البلوتوثتحليل الثغرات الأمنيةالاستغلالأمن الجوالالأوراق والأبحاثاستغلال الملفات الثنائية
GitHubidkwim/cve-2020-0022

CVE-2020-0022

مستودع بحثي يوثّق تجارب BlueFrag (CVE-2020-0022) المتعلقة بفيض كومة Bluetooth في Android، بما في ذلك تحليل انهيار GDB ومحاولات استغلال memcpy.

عرض المستودع
822منذ 6 سنواتلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

CVE-2020-0022

يبدو أن Android 9-6 لديها نظام Bluetooth فرعي مشابه، بينما Android 5 و 4 مختلفان.

Android 9.0

تجارب BlueFrag

التصحيح:

https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf

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

همممم

BlueFrag

في الواقع، تمكنت من تمرير قيمة الطول المُوقَّعة إلى memcpy()``` 02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch reassemble_and_dispatch 02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch partial_packet->offset 40 packet->len 304 HCI_ACL_PREAMBLE_SIZE 4
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch projected_offset 340 partial_packet->len 41
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch got packet which would exceed expected length of 41. Truncating. 02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch memcpy packet->len 1 packet->offset 4 expr -3
02-16 01:44:49.096 6423 6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch partial_packet->data 0xacb14580 partial_packet->data + partial_packet->offset 0xacb145a8 packet->data 0xa553e110 packet->data + packet->offset 0xa553e114
02-16 01:44:49.097 6423 6469 W bt_hci_packet_fragmenter: fragment_and_dispatch fragment_and_dispatch

لا يزال لا يوجد انهيار، لكن يجب أن يحدث.....


في المثال أعلاه، مع حجم memcpy يساوي -3، يتم تفسير هذه القيمة كعدد صحيح غير مُوقّع (4294967293) ويستمر memcpy حتى يحدث خطأ في الصفحة بسبب ذاكرة غير مُعيَّنة ويجب أن تنتهي العملية.

هاتفي يعمل بـ 32 بت، ربما هذا هو السبب. الجهاز هو Samsung S3 Neo+. باستخدام jemalloc على الأقل في اختبارات Android 9.0.```
¯\_(ツ)_/¯

حسنًا، يبدو صحيحًا

GDB log memcpy

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

نحن ندفع هنا 4294967293 أي ما يقرب من 4GB``` ¯_(ツ)_/¯

وجد Swing و leommxj هذا السلوك الغريب في Android 8:

https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fbestwing.me%2FAndroid-8.1-memcpy-func.html
(مترجم من الصينية)

من المحتمل أنه يؤثر أيضًا على Android 9. سأتحقق من ذلك.

في الواقع، قد يكون هذا لا يعمل في سياق العملية، ولكن ربما في سياق المقاطعة. عندها ربما يمكن
إخفاء الخطأ.
تنزيل الأداة