Ushbu tadqiqot Android 9 dan Android 14 gacha Android Runtime tuzilmasi qanday o‘zgarganini va bu o‘zgarishlarning foydalanuvchi makoni xotira kriminalistikasiga ta’sirini tizimli ravishda o‘lchaydi. Android Runtime (ART) — Android ilovalarining bajarilishini qo‘llab-quvvatlaydigan, obyekt yaratish, thread hayot sikli va xotirani boshqarish kabi bajarilish vaqti funksiyalarini boshqaradigan asosiy dasturiy qatlamdir. Tadqiqotchilar oltita Android versiyasini ARM32, ARM64, x86-32 va x86-64 dan iborat to‘rtta arxitekturada AOSP manbalaridan yig‘ib, har bir build dagi libart.so faylining DWARF debug ma’lumotlarini maxsus parser yordamida ajratib olib, tuzilma nomlari, tuzilma o‘lchamlari, a’zolar va xotira ofsetlarini versiyalar bo‘yicha taqqoslagan.

Tadqiqotning eng muhim natijasi shuki, bir tuzilma yoki maydonning keyingi Android versiyasida ayni nom bilan mavjud bo‘lishi uning xotirada ayni joyda bo‘lishini anglatmaydi. Versiyalar davomida mavjud bo‘lib qolgan tuzilma a’zolarining %73,2 qismi kamida bir marta ofsetini o‘zgartirgan. Runtime tuzilmasidagi a’zolarning %89,4 qismi, thread boshqaruvi bilan bog‘liq a’zolarning esa %64,7 qismi kamida bir marta qayta joylashtirilgan. Bunday harakatchanlik statik tuzilma ta’riflari va qat’iy ofsetlarga tayanuvchi kriminalistik tahlil vositalarining yangi Android versiyasida noto‘g‘ri ma’lumot o‘qishiga yoki butunlay ishlamay qolishiga olib kelishi mumkin.

Android 9–14 oralig‘ida ko‘rib chiqilgan 34 muhim kriminalistik tuzilma uchun Jadval II jami 1067 ta strukturaviy o‘zgarishni ko‘rsatadi: 956 ta ofset o‘zgarishi, 68 ta yangi a’zo, 39 ta olib tashlangan a’zo va to‘rtta butun tuzilmaning olib tashlanishi. O‘zgarishlarning taxminan %89,6 qismi faqat a’zolarning tuzilma ichidagi joylashuvi o‘zgarishidan iborat. Shu sababli ko‘rinishda kichik bo‘lgan manba-kod o‘zgarishi ham xotira tasvirini talqin qiluvchi vositaning farazlarini buzishi mumkin.

Tadqiqot symbol-based usullardan voz kechishni taklif qilmaydi. Aksincha, symbol lar beradigan tekshiriluvchanlik va kuzatuvchanlikni saqlab qolish, biroq buni versiyadan xabardor parsing, avtomatik tuzilma ajratish, symbolic execution, xotiraga murojaat naqshlarini tahlil qilish va zaxira discovery yo‘llari bilan birlashtirish kerakligini ta’kidlaydi. Natijalar Android 9–14 uchun AOSP ning eng build lariga asoslanganligi sababli OEM ishlab chiqaruvchi o‘zgartirishlari, turli build rejimlari va Android 15 dan keyingi versiyalar to‘g‘ridan-to‘g‘ri sinovdan o‘tkazilmagan.

Nega xotira kriminalistikasi faqat diskni tekshirishdan iborat emas?

Ilova ishlayotgan paytda muhim ma’lumotlar faqat doimiy saqlash qurilmasida bo‘lmaydi. Ochiq ilova holatlari, vaqtinchalik foydalanuvchi o‘zaro ta’sirlari, yechilgan obyektlar, bajarilish vaqti metadata si va hali diskka yozilmagan boshqa ma’lumotlar RAM ichida bo‘lishi mumkin. Foydalanuvchi makoni xotira kriminalistikasi aynan ilovaga xos ushbu vaqtinchalik ma’lumotlarni tushunishga harakat qiladi.

Biroq xom xotira tasvirida ma’lum byte ketma-ketligi nimani anglatishi o‘z-o‘zidan ma’lum emas. Tahlil vositasi bir Runtime, Thread, Heap, Class yoki boshqa C++ tuzilmasi qaysi a’zolardan iborat ekanini va har bir a’zo tuzilmaning boshlanishidan necha byte uzoqlikda joylashganini bilishi kerak. Bu masofa xotira ofseti deb ataladi.

Masalan, bir vosita thread ro‘yxati manzili Runtime tuzilmasida muayyan ofsetda joylashgan deb faraz qilsa, Android ning yangi versiyasida boshqa a’zolar qo‘shilishi sababli bu maydon bir necha o‘n byte siljiganda eski vosita endi thread ro‘yxatini emas, boshqa maydonni o‘qishi mumkin. Xotira kriminalistikasida bitta noto‘g‘ri manzilni yechish keyingi barcha obyekt zanjiriga ta’sir qilishi mumkin.

Android Runtime (ART) Nima va Xotira Kriminalistikasi Uchun Nega Muhim?

Android Runtime (ART) — Android ilovalari bajarilishi davomida xotira ajratishni, obyekt hayotini, thread boshqaruvini, garbage collection jarayonlarini va ilova kodi bajarilishi bilan bog‘liq ko‘plab ichki tuzilmalarni boshqaradigan bajarilish vaqti tizimidir. Foydalanuvchi makoni xotira kriminalistikasi ushbu tuzilmalardagi pointer, a’zo va munosabatlarga tayangan holda thread larni, heap hududlarini va ilova obyektlarini qayta tiklay olgani uchun ART ning versiyalar o‘rtasidagi strukturaviy o‘zgarishi kriminalistik vositalarning ishonchliligiga bevosita ta’sir qiladi.

Dalvik dan ART ga o‘tish nega muhim edi?

Android ning bajarilish vaqti arxitekturasi vaqt o‘tishi bilan sezilarli darajada o‘zgargan. Dalvik davridan ART ga o‘tish faqat nom o‘zgarishi emas edi; ilova kodini bajarish usuli, xotira ajratish, garbage collection va ichki ma’lumot tuzilmalari ham o‘zgargan. ART bilan birga RosAlloc kabi xotira ajratuvchilar va keyingi versiyalarda Region Space Allocation kabi tuzilmalar kriminalistik tahlil nuqtai nazaridan muhimlashgan.

RosAlloc heap xotirasini ma’lum o‘lchamdagi obyektlar uchun slotlardan tashkil topgan hududlarga ajratadi. Kattaroq obyektlar esa Large Object Space kabi boshqa hududlarga ko‘chirilishi mumkin. Android 8 dan keyin Concurrent Copying va Region Space Allocation asosiy mexanizmlarga aylangani eski xotira tiklash usullarini yangi versiyalarga to‘g‘ridan-to‘g‘ri ko‘chirishni qiyinlashtirgan.

Bu yerdagi asosiy masala shuki, Android umumiy ART karkasini saqlab qolsa ham uning ichki tuzilmalari o‘zgarmasdan qolmaydi. Ayni funksiya yillar davomida mavjud bo‘lishi mumkin, ammo unga kirish uchun ishlatiladigan tuzilma, pointer zanjiri yoki a’zo joylashuvi o‘zgarishi mumkin.

Tadqiqotning beshta tadqiqot savoli

Nega to‘rtta arxitektura o‘rganildi?

Tadqiqotchilar ARM va x86 oilalarining ham 32-bit, ham 64-bit versiyalarini o‘rgangan: ARM32, ARM64, x86-32 va x86-64. Buning sababi faqat Android versiyasi emas, protsessor arxitekturasi ham pointer o‘lchami, alignment va xotira layout iga ta’sir qilishi mumkinligidir.

Shu bilan birga, bir Android versiyasidagi to‘rtta arxitekturada symbol sonlari nihoyatda yaqin ekanligi ko‘rilgan. Masalan, Android 14 uchun symbol soni ARM64 da 19.115, x86-64 da 19.100, ARM32 da 19.107 va x86-32 da 19.097. Shu sababli tadqiqotchilar batafsil mikro-strukturaviy taqqoslashda x86-64 ni vakil arxitektura sifatida qo‘llagan. Bu qaror byte darajasidagi barcha arxitektura layout lari bir xil degani emas; manba ayniqsa alignment farqlari xotira joylashuviga ta’sir qilishi mumkinligini ta’kidlaydi.

Symbol-Based Xotira Kriminalistikasi Nima?

Symbol-based yoki profil-based xotira kriminalistikasi kompilyator hosil qilgan debug ma’lumotlaridan ma’lumot tuzilmalarining nomlari, o‘lchamlari, a’zolari va a’zo ofsetlarini ajratib olib, xotira tasviriga ma’no berishga asoslangan yondashuvdir. Bu usul yuqori kuzatuvchanlik va tekshiruv imkonini beradi; ammo tuzilma ta’riflari har Android versiyasida o‘zgarganda profillar va ulardan foydalanadigan parsing kodi doimiy ravishda yangilanib turishi kerak.

DWARF bu yerda nima qiladi?

DWARF kompilyatsiya qilingan binary fayllarda debug maqsadida tuzilma va o‘zgaruvchi ma’lumotlarini saqlashi mumkin bo‘lgan debug information formatidir. Tadqiqot libart.so ichidagi DWARF ma’lumotidan foydalanib ART ning C++ tuzilmalari nomlarini, umumiy byte o‘lchamlarini va a’zolarning tuzilma ichidagi joylashuvlarini ajratib oladi.

ART C++ inheritance, template va murakkab obyektga yo‘naltirilgan tuzilmalardan keng foydalanishi sababli standart dwarf2json yondashuvi tadqiqotchilar ehtiyojini qondirmagani aytiladi. Shu sababli pyelftools asosidagi maxsus parser ishlab chiqilgan.

Parser DWARF ichidagi Compilation Unit lar va Debugging Information Entry yozuvlarini ko‘rib chiqadi; DW_TAG_class_type, DW_TAG_structure_type va DW_TAG_member kabi yozuvlar yordamida tuzilma nomini, byte o‘lchamini va DW_AT_data_member_location orqali a’zo joylashuvini ajratib oladi. Olingan ma’lumotlar har bir versiya va arxitektura uchun strukturaviy JSON fayllariga aylantiriladi.

Tadqiqot qamrovi chegarasi

Tadqiqot Android 9, 10, 11, 12, 13 va 14 ni qamrab oladi. Android 15 tadqiqot boshlangan paytda hali chiqarilmagani uchun tahlilga kiritilmagan. Barcha build larda ishlab chiqish va debug imkoniyatlarini beradigan AOSP eng build varianti ishlatilgan.

Manba, shuningdek, Android ning user, debug, eng va release kabi turli build konfiguratsiyalari; arxitektura tanlovlari va Samsung kabi OEM ishlab chiqaruvchilarining moslashtirishlari tuzilmalar soni, ma’lumot turi va o‘lchamlarida qo‘shimcha farqlar yaratishi mumkinligini ochiq aytadi. Shuning uchun tadqiqot natijalarini “barcha tijoriy Android telefonlarida byte darajasida bir xil tuzilmalar bor” tarzida talqin qilib bo‘lmaydi.

Tadqiqot Usuli va Natijalari

Tadqiqot jarayoni

Manbadagi tadqiqotning 5-betidagi 1-rasm ham shu mantiqni ko‘rsatadi: AOSP versiyalari avval build qilinadi va symbol lari ajratib olinadi; so‘ng makro va mikro darajadagi tahlillar bajariladi; natijalar thread, heap va obyekt recovery ga ta’sirlar bilan bog‘lanib, takliflarga aylantiriladi.

Build muhiti

AOSP build lari Linux asosidagi tizimda bajarilgan. Manba tajriba mashinasini 13-avlod Intel Core i9-13900KF protsessori, 64 GB RAM va 4 TB saqlash bilan tavsiflaydi. Har bir versiya uchun alohida va toza build environment tashkil qilingan; Git, Python, OpenJDK va Android Repo vositasi ishlatilgan. Manba har bir versiya build i taxminan 4–5 soat davom etganini xabar qiladi.

Nega 34 ta tuzilma tanlandi?

Yangi Android versiyalaridagi libart.so fayllarida 19.000 dan ortiq DWARF symbol mavjud bo‘lgani sababli barcha tuzilmalarni kriminalistik ahamiyat bo‘yicha alohida tahlil qilish o‘rniga 34 ta muhim ma’lumot tuzilmasiga e’tibor qaratilgan. Bu tuzilmalar Android 8, 8.1 va 9 ni qo‘llab-quvvatlaydigan DroidScraper nomli foydalanuvchi makoni xotira kriminalistikasi vositasini yangi versiyalarga ko‘chirish uchun qaysi past darajadagi tuzilmalar kerak bo‘lishini o‘rganish orqali aniqlangan.

Tanlangan tuzilmalar guruhida Runtime, Thread va Heap bilan birga thread enumeration, memory mapping va object recovery uchun zarur yordamchi tuzilmalar mavjud.

RQ1 — ART kutubxonasi o‘lchami qanday o‘zgardi?

Binary o‘lchami monoton tarzda oshmaydi. x86-64 uchun Android 10 dagi 147,36 MB dan Android 11 da 200,71 MB gacha oshgan; manba buni taxminan %36 o‘sish deb talqin qiladi. Android 13 da esa barcha arxitekturalarda sezilarli kichrayish kuzatiladi. ARM64 misolida Android 12 dagi 177,09 MB fayl Android 13 da 89,76 MB gacha kamaygan.

Tadqiqotchilar readelf orqali tekshiruvda Android 9–12 DWARF 4 dan, Android 13 va 14 esa DWARF 5 dan foydalanishini aniqlagan. Manba DWARF 5 ma’lumotlarni zichroq paketlashga hissa qo‘shishi mumkinligini aytadi, shu bilan birga binary o‘lchamiga compiler flag, debug information miqdori va optimizatsiya tanlovlari ham ta’sir qilishi mumkinligini ogohlantiradi. Shu sababli taxminan 48% o‘lcham kamayishini ART funksiyasi yo‘qolishi deb talqin qilish to‘g‘ri emas.

RQ2 — Debug symbol lar soni qanday o‘zgardi?

ARM64 symbol soni Android 9 dagi 15.698 dan Android 14 da 19.115 gacha oshgan; manba buni taxminan %22 o‘sish deb xabar qiladi. Android 13 da qisqa muddatli pasayish kuzatilgan bo‘lsa-da, Android 14 o‘rganilgan davrning eng yuqori symbol soniga ega.

Bu yerdagi muhim natija shuki, binary o‘lchami Android 13 va 14 da jiddiy kamaygan bo‘lsa ham, debug symbol lar soni uzoq muddatda ortgan. Shuning uchun “fayl kichraydi, runtime soddalashdi” degan xulosa chiqarib bo‘lmaydi. Manbaning talqini DWARF 5 kabi samaraliroq kodlash boy debug ma’lumotini kichikroq binary ichida saqlashi mumkinligi yo‘nalishidadir.

RQ3 — 34 ta muhim tuzilmada nechta o‘zgarish topildi?

1067 ta o‘zgarishning 956 tasi a’zolarning tuzilma ichidagi joylashuvi o‘zgarishidir. Bu taxminan %89,60 ga teng. A’zo qo‘shilishlari taxminan %6,37, a’zo olib tashlashlari taxminan %3,66 va butun tuzilma olib tashlashlari taxminan %0,37 ni tashkil qiladi.

Eng ko‘p o‘zgarish Android 9→10 o‘tishida kuzatilgan. Keyin Android 11→12 o‘tishida umumiy o‘zgarishlar soni 109 gacha kamaygan, biroq Android 12→13 va 13→14 davrlarida yana sezilarli strukturaviy harakatchanlik kuzatilgan.

Manba bayonidagi 355 va 201 raqamlari butun tuzilma olib tashlashlarini jami hisobga qo‘shmagani uchun yuqoridagi jadval to‘g‘ridan-to‘g‘ri manba Jadval II qiymatlari asosida tayyorlangan.

Nega Bitta Xotira Ofsetining O‘zgarishi Kriminalistik Tahlilni Buzishi Mumkin?

Xotira kriminalistikasi vositalari ko‘pincha ma’lumot tuzilmasining muayyan a’zosiga tuzilma boshidan qat’iy byte masofasi orqali murojaat qiladi; Android yangilanishi ayni a’zoni boshqa ofsetga ko‘chirganda eski profil noto‘g‘ri xotira joyini o‘qishi mumkin. Agar bu xato thread ro‘yxati, heap pointer yoki obyektning class ma’lumoti boshlanish nuqtasida yuz bersa, keyingi pointer dereference amallari ham noto‘g‘ri zanjirni kuzatishi va yuqori darajadagi kriminalistik reconstruction jarayoni muvaffaqiyatsiz bo‘lishi mumkin.

RQ4 — Runtime, Thread va Heap bir xil tarzda evolyutsiya qilmagan

Manba ART ning uchta markaziy tuzilmasi bir-biridan farqli evolyutsiya naqshini ko‘rsatganini xabar qiladi.

9-betdagi 2-rasm bu farqni ayniqsa yaqqol ko‘rsatadi: Thread tuzilmasi Android 9→10 o‘tishida keskin sakraydi, Runtime esa o‘zgaruvchanroq o‘sish chizig‘ini kuzatadi, Heap esa cheklanganroq o‘zgaradi. Tadqiqotchilar Android 10 dagi Thread o‘sishining muhim sabablaridan biri sifatida 4000 byte dan ko‘proq joy egallaydigan yangi interpreter_cache_ a’zosini ko‘rsatadi.

Ta’sir skori nimani ko‘rsatadi?

Tadqiqotchilar strukturaviy o‘zgarishning faqat sonini emas, uning intensivligini ham ko‘rsatish uchun 0 dan 1 gacha bo‘lgan ta’sir skori ishlab chiqqan. Skor uch unsurni birgalikda baholaydi: ofset o‘zgarishidan ta’sirlangan a’zolar ulushi, qo‘shilgan yoki olib tashlangan a’zolarning jami a’zolarga nisbati va tuzilma o‘lchamidagi nisbiy o‘zgarish kattaligi.

Manba bu o‘lchovning yopiq-form tenglamasini bermagani uchun bu yerda yangi formula chiqarilmaydi. 10-betdagi 3-rasm heatmap ida Runtime uchun Android 9→10 ofset o‘zgarishi ta’siri 0,90 darajasida. Thread ayni o‘tishda yuqori o‘zgarishni ko‘rsatsa, keyingi versiyalarda ko‘p ko‘rsatkichlarda pastroq ta’sir skorlariga tushadi. Heap umumiy holda pastroq va barqaror ta’sir darajalarida qoladi.

RQ5 — Thread enumeration qanday ta’sirlanadi?

Android jarayonidagi thread larni topish uchun Runtime tuzilmasidan thread_list_ maydoniga kirish va undan ThreadList ichidagi ikki tomonlama bog‘langan thread zanjirini kuzatish kerak. Biroq thread_list_ maydonining ofseti Android 9 dan 14 gacha quyidagicha o‘zgargan:

Bu yerda bir yo‘nalishli, oldindan aytish mumkin bo‘lgan o‘sish yoki kamayish naqshi yo‘q. Oldingi versiyaning qat’iy qiymatini yangi versiyaga ko‘chirish xavfsiz emas.

Thread identifikatorini yechishda ishlatiladigan name_ va tid_ kabi maydonlar ham o‘rganilgan versiyalarning taxminan yarmida joylashuvini o‘zgartirgani xabar qilingan. tls_32bit_sized_values ichidagi park_state_ maydoni Android 10 da 60 ofsetida paydo bo‘lgan, Android 14 da esa 44 ofsetiga ko‘chgan.

Heap tahlili qanday ta’sirlanadi?

Heap tahlilining asosiy kirish nuqtalaridan biri yana Runtime ichidagi heap_ pointer idir. Tadqiqotda ushbu maydon Android 9→14 davomida ketma-ket 448 → 400 → 392 → 416 → 512 → 512 ofsetlarda joylashgani ko‘rsatilgan.

Heap ichidagi region_space_ maydoni ham Android 9 dagi 728 ofsetdan Android 14 da 840 ofsetga ko‘chgan. RegionSpace ichida hududlar sonini tushunishda ishlatiladigan num_regions_ kabi muhim maydonlar ham bir necha marta qayta joylashtirilgani aytiladi.

Bu o‘zgarishlar faqat “bir manzilni yangila” muammosi emas; thread lar Thread Local Allocation Buffer dan foydalanib heap hududlariga obyekt ajratishi mumkinligi sababli thread, heap va object-recovery ma’lumotlari o‘zaro bog‘langan.

Obyekt reconstruction nega qiyinlashdi?

Ilova darajasidagi dalillar ko‘pincha klasslarning instance lari va shu obyektlardagi instance yoki static field lar shaklida xotirada joylashadi. Shu sababli Android obyektini to‘g‘ri class tuzilmasiga bog‘lash va uning field larini yechish foydalanuvchi makoni kriminalistik tahlilining markazida turadi.

Android 9–12 davrida Object va Class bilan bog‘liq maydonlarda ofset o‘zgarishlari kuzatilgan bo‘lsa, Android 12→13 o‘tishida yanada asosiy o‘zgarish yuz bergan: tadqiqot Object va Class ni ham o‘z ichiga olgan ayrim asosiy tuzilmalar libart.so ichidan olib tashlanganini xabar qiladi. Bu eski tahlil kodining faqat yangi ofset jadvali bilan davom etishini qiyinlashtiradi.

Android 10 dagi JIT o‘zgarishi nega faqat tuzilma o‘lchamidan muhimroq?

Manba Android 9→10 davrida profiler-based Just-In-Time compilation qo‘llab-quvvatlashi bilan birga JitCodeCache va ProfilingInfo kabi tuzilmalar paydo bo‘lganini aytadi.

Android 9 va undan oldingi tuzilishlarda DexFile instance lari OATFile lar ichida joylashgan va ularga OatFileManager orqali kirish mumkin edi. DroidScraper kabi vositalar shu aloqadan foydalanib DexFile instance lariga yetib bora olgan.

Android 10 dan keyin OatFileManager ilovaga xos OAT fayllarining ayni tarzdagi menejeri bo‘lishdan chiqqan. Manba yangi versiyalarda ilova DexFile instance lariga kirish uchun quyidagi murakkabroq aloqa zanjirini kuzatish kerakligini tushuntiradi:

JitCodeCache → ProfilingInfo → ArtMethod → DexCache → DexFile

Bu misol tadqiqotning asosiy xabarini kuchli ko‘rsatadi: yangi Android versiyasida barcha ofsetlarni to‘g‘ri bilish ham eski algoritm ishlashiga kafolat bermaydi; ba’zan tuzilmalar o‘rtasidagi semantik munosabat va kirish yo‘li ham o‘zgaradi.

Eng keng natija: %73,2 strukturaviy joylashuv o‘zgarishi

Muhokama bo‘limida tadqiqotchilar versiyalar orasida mavjud bo‘lib qolgan barcha tuzilma a’zolarini birgalikda baholagan. Bu a’zolarning %73,2 qismi Android 9–14 oralig‘ida kamida bir marta boshqa ofsetga ko‘chgan.

Runtime ning %89,4 ko‘rsatkichi ayniqsa muhim; chunki Runtime ko‘plab boshqa tuzilmalarga kirishning markazida turadi. Bunday markaziy tuzilmaning keng ko‘lamli qayta joylashuvi bitta plugin yoki parser funksiyasidan ko‘ra kengroq kod zanjiriga ta’sir qilishi mumkin.

Android Xotira Kriminalistikasi Vositalarida Faqat Ofsetlarni Yangilash Yetarlimi?

Yo‘q. Tadqiqot ayrim Android o‘tishlarida nafaqat tuzilma a’zolarining joylashuvi, balki tuzilmalarning mavjudligi, kutubxonalar orasidagi o‘rni va boshqa tuzilmalarga kirish yo‘llari ham o‘zgarishini ko‘rsatadi. Shu sababli yangi versiyaga moslashtirish ba’zan qat’iy ofset jadvalini yangilashdan ancha ko‘proqni; versiyadan xabardor parsing, muqobil discovery yo‘llari va semantik munosabatlarni qayta tiklay oladigan tahlil texnikalarini talab qiladi.

Mualliflar taklif qilgan gibrid yondashuv

Tadqiqotchilar symbol-based kriminalistikadan butunlay voz kechishga qarshi. Symbol lar tuzilmalarning ma’nosini va manba kodi bilan kuzatuvchanligini ta’minlagani sababli kriminalistik tekshiruv uchun qimmatlidir. Muammo ularning yakka holda qo‘llanishidadir.

Taklif qilinayotgan kelajak vosita arxitekturasida bir nechta imkoniyatni birgalikda ishlatish ta’kidlanadi:

• Tuzilma ta’riflarini Android versiyasiga qarab tanlaydigan versiyadan xabardor parsing.
• Qat’iy layout bilan parser mantiqini bir-biridan ajratadigan modulli arxitektura.
• Versiyaga xos tuzilma xaritalari bilan umumiy tahlil kodini birgalikda ishlatish.
• Runtime va Thread kabi muhim kirish nuqtalari uchun bir nechta discovery yo‘li.
• Symbol ishlamaganida memory scanning yoki xulq-atvor pattern tracing kabi zaxira usullar.
• Tuzilmalarning kod ichida qanday ishlatilishini tahlil qiladigan symbolic execution.
• Kelajakda directed symbolic execution bilan memory-access-pattern tahlilini birgalikda qo‘llash.

Manba Seance nomli oldingi proof-of-concept ishini symbolic execution imkoniyatiga misol sifatida keltiradi; biroq global variable reference laridagi ayrim o‘zgarishlarni aniqlay olmaslik kabi muammolarni ham ochiq qayd etadi. Shu sababli symbolic execution ham yakka holda mukammal yechim sifatida ko‘rsatilmaydi.

Tadqiqot qo‘llab-quvvatlaydigan xulosalar

• Android 9–14 oralig‘ida ART tuzilmalarining ichki layout lari sezilarli darajada o‘zgaradi.
• 34 ta muhim tuzilmada eng ko‘p uchraydigan o‘zgarish turi a’zo ofsetlarining qayta joylashtirilishidir.
• Runtime, Thread va Heap bir xil evolyutsiya naqshini ko‘rsatmaydi.
• Thread enumeration, heap analysis va object reconstruction bu o‘zgarishlardan bevosita ta’sirlanadi.
• Static symbol/profile yondashuvini yakka holda davom ettirish tobora ko‘proq texnik xizmat talab qiladi.
• Strukturaviy munosabatlar o‘zgarganda faqat ofset jadvallarini yangilash yetarli bo‘lmasligi mumkin.
• Tekshiriladigan symbolic ma’lumotni moslashuvchanroq usullar bilan birlashtiradigan gibrid dizayn tadqiqotchilar taklif qilgan yo‘nalishdir.

Tadqiqot qo‘llab-quvvatlamaydigan xulosalar

• Barcha tijoriy Android telefonlari o‘rganilgan AOSP eng build lari bilan bir xil xotira layout iga ega ekani ko‘rsatilmagan.
• Samsung yoki boshqa OEM larning moslashtirilgan firmware lari to‘g‘ridan-to‘g‘ri taqqoslanmagan.
• Android 15 va undan keyingi versiyalar tajriba qamroviga kiritilmagan.
• Taklif qilingan gibrid usullarning barchasi production darajasida ishlaydigan yagona yangi kriminalistik vositada ustun ekani eksperimental ravishda ko‘rsatilmagan.
• Symbolic execution barcha tuzilma o‘zgarishlarini mukammal aniqlaydigan yechim sifatida isbotlanmagan.
• Tadqiqot haqiqiy sud ishida dalilning qabul qilinishini o‘lchaydigan huquqiy validatsiya tajribasi emas.

Metodologik talqin chegaralari

Tadqiqotning kuchli tomoni ayni AOSP versiyalarining to‘rtta arxitekturada qayta build qilinib taqqoslanishi va strukturaviy ma’lumotning bevosita DWARF yozuvlaridan ajratib olinishi hisoblanadi. Bu versiyalararo o‘zgarishni tizimli ravishda o‘lchash imkonini beradi.

Biroq barcha build lar AOSP eng konfiguratsiyasiga asoslangan. Manbaning o‘zi Android ning turli build rejimlari va OEM moslashtirishlari tuzilmalar soni, turi va o‘lchamlariga ta’sir qilishi mumkinligini aytadi. Shu sababli real qurilmalarda uchrashi mumkin bo‘lgan xilma-xillik bu tadqiqot dizaynidan kengroq bo‘lishi mumkin.

Shuningdek, mikro darajadagi tuzilma taqqoslash asosan x86-64 da bajarilgan. Tadqiqotchilar bu tanlovni ayni Android versiyasi ichida symbol soni va tuzilma munosabatlari arxitekturalar o‘rtasida juda o‘xshashligi bilan asoslaydi; biroq manba alignment sababli haqiqiy xotira layout farqlari mavjud bo‘lishi mumkinligini ham tan oladi.

Android 15 tadqiqot boshlanganda chiqarilmagani uchun tahlil Android 14 da yakunlanadi. Natijalar Android ning keyingi versiyalarida qaysi tuzilmalar o‘zgarishini aniq bashorat qilish uchun ishlatilmasligi kerak.

Manba va Usul Haqida Izoh

Asl tadqiqot: Exploring Runtime Evolution in Android: A Cross-Version Analysis and Its Implications for Memory Forensics

Mualliflar: Babangida Bappah, Lauren G Bristol, Lamine Noureddine, Sideeq Bello, Umar Farooq va Aisha Ali-Gombe

Tashkilot: Louisiana State University, USA

Nashr turi: Taqrizlangan konferensiya maqolasi.

Konferensiya: 28th International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2025).

Nashr yili: 2025.

Sahifalar: 349–362.

Nashriyot: IEEE Computer Society.

DOI: 10.1109/RAID67961.2025.00040

arXiv versiyasi: arXiv:2512.18517; arXiv yuklangan sana 20 Dekabr 2025.

Asosiy tadqiqot turi: Android Runtime ma’lumot tuzilmalarining versiyalararo empirik va hisoblashga asoslangan o‘lchov tahlili.

O‘rganilgan Android versiyalari: Android 9, 10, 11, 12, 13 va 14.

O‘rganilgan arxitekturalar: ARM32, ARM64, x86-32 va x86-64.

Build konfiguratsiyasi: AOSP eng build.

Asosiy binary: libart.so.

Strukturaviy ma’lumot manbai: DWARF debug ma’lumoti.

Parser: ART ning C++ tuzilmasi uchun maxsus ishlab chiqilgan, pyelftools dan foydalanadigan maxsus parser.

Tahlil usullari: Cross-Version Binary Profiling va Symbol-Based Structural Evolution Analysis.

Batafsil mikro tahlil qamrovi: Xotira kriminalistikasi uchun muhim 34 ta ART ma’lumot tuzilmasi.

Ma’lumot/repository holati: Manba tadqiqot Android 9–14 uchun ajratib olingan runtime structure ma’lumotlari va tadqiqot framework i ommaga ochiq tadqiqot repository sida saqlanishini bildiradi.

Moliyalashtirish: Tadqiqot Department of Homeland Security (DHS) tarkibidagi Criminal Investigations and Network Analysis Center (CINA), Grant No. E206378P tomonidan qo‘llab-quvvatlangan.

Manfaatlar to‘qnashuvi: Taqdim etilgan PDF da alohida manfaatlar to‘qnashuvi bayonoti aniqlanmagan.

Muallif hissalari: Taqdim etilgan PDF da alohida CRediT/muallif hissalari bo‘limi berilmagan.

Litsenziya: Taqdim etilgan PDF ichida ishonchli tarzda tasdiqlanadigan ochiq litsenziya turi topilmagani uchun himoyalangan matn va asl shakllardan qayta foydalanishda ochiq litsenziya mavjud deb faraz qilinmagan. Verianla bayoni ilmiy faktlar, usullar va xabar qilingan miqdoriy natijalar asosida mustaqil ravishda tuzilgan.

Manba ichidagi miqdoriy nomuvofiqlik: Jadval II Android 9→10 uchun 356 va Android 12→13 uchun 204 jami o‘zgarishni ko‘rsatgan bo‘lsa, atrofdagi bayon mos ravishda 355 va 201 ni beradi. Farq bayondagi hisob-kitob butun tuzilma olib tashlashlarini jami hisobdan tashqarida qoldirganidan kelib chiqadi. Verianla jadvallarida manba Jadval II ning kategoriya bo‘yicha qiymatlari saqlangan.

Asosiy talqin chegarasi: Tadqiqot AOSP eng build larini va Android 9–14 davrini o‘rganadi. OEM firmware xilma-xilligi, boshqa build profillari va Android 15 dan keyingi tuzilmalar to‘g‘ridan-to‘g‘ri o‘lchanmagan. Taklif etilgan gibrid kriminalistik tahlil yondashuvi kelajakdagi vosita ishlab chiqish uchun ilmiy taklifdir; ushbu tadqiqotda barcha komponentlarni birlashtirgan yangi production vositasining real sharoitdagi muvaffaqiyati sinovdan o‘tkazilmagan.

Mualliflik huquqi va bayon usuli: Manbaning asl gaplari, paragraf ketma-ketligi yoki shakl dizaynlari qayta ishlab chiqilmagan. Verianla matni manbada xabar qilingan tuzilma o‘zgarishlari, binary va symbol o‘lchovlari, ofset qiymatlari, usul bosqichlari va talqin chegaralarini ajratib olib, mustaqil o‘rgatuvchi arxitektura asosida tuzilgan.