Bu tədqiqat Android 9-dan Android 14-ə qədər Android Runtime-ın struktur baxımından necə dəyişdiyini və bu dəyişikliklərin istifadəçi məkanı yaddaş kriminalistikasına təsirini sistemli şəkildə ölçür. Android Runtime (ART), Android tətbiqlərinin icrasını dəstəkləyən; obyekt yaradılması, thread həyat dövrü və yaddaş idarəetməsi kimi icra zamanı funksiyalarını idarə edən əsas proqram qatıdır. Tədqiqatçılar altı Android versiyasını ARM32, ARM64, x86-32 və x86-64 olmaqla dörd arxitekturada AOSP mənbələrindən yığıb; hər yığımdakı libart.so faylının DWARF sazlama məlumatlarını xüsusi ayrışdırıcı ilə çıxararaq struktur adlarını, struktur ölçülərini, üzvləri və yaddaş ofsetlərini versiyalar arasında müqayisə ediblər.

Tədqiqatın ən mühüm nəticəsi ondan ibarətdir ki, bir strukturun və ya sahənin eyni adla sonrakı Android versiyasında mövcud olması onun eyni yaddaş mövqeyində olacağı demək deyil. Versiyalar boyunca mövcudluğunu qoruyan struktur üzvlərinin %73,2-si ən azı bir dəfə ofset dəyişib. Runtime strukturundakı üzvlərin %89,4-ü, thread idarəetməsi ilə əlaqəli üzvlərin isə %64,7-si ən azı bir dəfə yenidən yerləşdirilib. Bu hərəkətlilik statik struktur təriflərinə və sabit ofsetlərə əsaslanan kriminalistik analiz alətlərinin yeni Android versiyasında yanlış məlumat oxumasına və ya tamamilə işləməz hala gəlməsinə səbəb ola bilər.

Android 9–14 arasında araşdırılan 34 kritik kriminalistik struktur üçün Cədvəl II ümumilikdə 1067 struktur dəyişikliyi göstərir: 956 ofset dəyişikliyi, 68 yeni üzv, 39 silinmiş üzv və dörd bütöv strukturun silinməsi. Dəyişikliklərin təxminən %89,6-sı yalnız üzvlərin struktur daxilindəki mövqeyinin dəyişməsidir. Buna görə zahirən kiçik bir mənbə-kod dəyişikliyi belə yaddaş görüntüsünü şərh edən alətin fərziyyələrini poza bilər.

Tədqiqat simvol-əsaslı metodlardan imtinanı təklif etmir. Əksinə, simvolların təmin etdiyi yoxlanıla bilənlik və izlənə bilənliyin qorunmasını; lakin bunun versiya-fərqində olan ayrışdırma, avtomatik struktur çıxarışı, simvolik icra, yaddaş giriş nümunəsi analizi və ehtiyat kəşf yolları ilə birləşdirilməsini müdafiə edir. Nəticələr Android 9–14 üçün AOSP-nin eng yığımlarına əsaslandığından OEM istehsalçı dəyişiklikləri, fərqli build rejimləri və Android 15-dən sonrakı versiyalar birbaşa sınaqdan keçirilməyib.

Yaddaş kriminalistikası niyə yalnız disk araşdırmasından ibarət deyil?

Tətbiq işləyərkən mühüm məlumatlar yalnız daimi yaddaşda olmur. Açıq tətbiq vəziyyətləri, müvəqqəti istifadəçi qarşılıqlı əlaqələri, həll edilmiş obyektlər, icra zamanı metadata-sı və hələ diskə yazılmamış digər məlumatlar RAM daxilində ola bilər. İstifadəçi məkanı yaddaş kriminalistikası xüsusilə tətbiqə xas bu müvəqqəti məlumatları anlamağa çalışır.

Lakin xam yaddaş görüntüsündə müəyyən byte ardıcıllığının nə demək olduğu öz-özünə bilinmir. Analiz aləti bir Runtime, Thread, Heap, Class və ya digər C++ strukturunun hansı üzvlərdən ibarət olduğunu və hər bir üzvün strukturun başlanğıcından etibarən neçə byte uzaqda yerləşdiyini bilməlidir. Bu məsafəyə yaddaş ofseti deyilir.

Məsələn, bir alət thread siyahısının ünvanının Runtime strukturunda müəyyən ofsetdə olduğunu fərz edirsə, Android-in yeni versiyasında başqa üzvlərin əlavə olunması səbəbindən bu sahə bir neçə onlarla byte sürüşdükdə köhnə alət artıq thread siyahısını deyil, başqa bir sahəni oxuya bilər. Yaddaş kriminalistikasında tək bir yanlış ünvan həlli sonrakı bütün obyekt zəncirinə təsir edə bilər.

Android Runtime (ART) Nədir və Yaddaş Kriminalistikası Üçün Niyə Kritikdir?

Android Runtime (ART), Android tətbiqlərinin icrası zamanı yaddaş ayırmasını, obyekt ömrünü, thread idarəetməsini, garbage collection proseslərini və tətbiq kodunun icrası ilə bağlı çoxsaylı daxili strukturları idarə edən icra zamanı sistemidir. İstifadəçi məkanı yaddaş kriminalistikası bu strukturlardakı pointer, üzv və əlaqələrə əsaslanaraq thread-ləri, heap bölgələrini və tətbiq obyektlərini yenidən qura bildiyi üçün ART-ın versiyalar arasındakı struktur dəyişimi birbaşa kriminalistik alətlərin etibarlılığına təsir edir.

Dalvik-dən ART-a keçid niyə mühüm idi?

Android-in icra zamanı arxitekturası zaman ərzində əhəmiyyətli dərəcədə dəyişib. Dalvik dövründən ART-a keçid yalnız ad dəyişikliyi deyildi; tətbiq kodunun icra forması, yaddaş ayırması, garbage collection və daxili məlumat strukturları da dəyişmişdi. ART ilə birlikdə RosAlloc kimi yaddaş ayırıcıları və sonrakı versiyalarda Region Space Allocation kimi strukturlar kriminalistik analiz baxımından mühüm hala gəlib.

RosAlloc heap yaddaşını müəyyən ölçülü obyektlər üçün slotlardan ibarət bölgələrə ayırır. Daha böyük obyektlər isə Large Object Space kimi fərqli sahələrə daşına bilər. Android 8-dən sonra Concurrent Copying və Region Space Allocation-ın əsas hala gəlməsi daha köhnə yaddaş bərpa texnikalarının birbaşa yeni versiyalara daşınmasını çətinləşdirib.

Buradakı əsas məsələ Android-in eyni ümumi ART çərçivəsini saxlamasına baxmayaraq daxili strukturlarının sabit qalmamasıdır. Eyni funksiya illərlə mövcud ola bilər, lakin ona çıxış üçün istifadə olunan struktur, pointer zənciri və ya üzv mövqeyi dəyişə bilər.

Tədqiqatın beş tədqiqat sualı

Niyə dörd arxitektura araşdırılıb?

Tədqiqatçılar ARM və x86 ailələrinin həm 32-bit, həm də 64-bit versiyalarını araşdırıblar: ARM32, ARM64, x86-32 və x86-64. Səbəb yalnız Android versiyasının deyil, prosessor arxitekturasının da pointer ölçüsünə, alignment-a və yaddaş yerləşiminə təsir göstərə bilməsidir.

Bununla yanaşı, simvol saylarının eyni Android versiyası daxilində dörd arxitekturada son dərəcə yaxın olduğu görülüb. Məsələn, Android 14 üçün simvol sayı ARM64-də 19.115, x86-64-də 19.100, ARM32-də 19.107 və x86-32-də 19.097-dir. Buna görə tədqiqatçılar təfərrüatlı mikro-struktur müqayisəsində x86-64-ü təmsilçi arxitektura kimi istifadə ediblər. Bu qərar byte səviyyəsində bütün arxitektur yerləşimlərinin eyni olduğu demək deyil; mənbə xüsusilə alignment fərqlərinin yaddaş yerləşiminə təsir göstərə bildiyini bildirir.

Simvol-Əsaslı Yaddaş Kriminalistikası Nədir?

Simvol-əsaslı və ya profil-əsaslı yaddaş kriminalistikası kompilyatorun yaratdığı sazlama məlumatlarından məlumat strukturlarının adlarını, ölçülərini, üzvlərini və üzv ofsetlərini çıxararaq yaddaş görüntüsünün mənalandırılmasına əsaslanan yanaşmadır. Bu üsul yüksək izlənə bilənlik və yoxlama gücü verir; lakin struktur tərifləri hər Android versiyasında dəyişdikdə profillərin və onlardan istifadə edən ayrışdırma kodunun davamlı yenilənməsi tələb olunur.

DWARF burada nə iş görür?

DWARF kompilyasiya olunmuş ikili fayllarda sazlama məqsədilə struktur və dəyişən məlumatlarını daşıya bilən debug information formatıdır. Tədqiqat libart.so daxilindəki DWARF məlumatından istifadə edərək ART-ın C++ strukturlarının adlarını, ümumi byte ölçülərini və üzvlərin struktur daxilindəki mövqelərini çıxarır.

ART-ın geniş şəkildə C++ inheritance, template və mürəkkəb obyekt-yönümlü struktur istifadə etməsi səbəbindən standart dwarf2json yanaşmasının tədqiqatçıların ehtiyacını qarşılamadığı bildirilir. Bunun üzərinə pyelftools əsaslı xüsusi parser hazırlanıb.

Parser DWARF daxilində Compilation Unit-ləri və Debugging Information Entry qeydlərini gəzir; DW_TAG_class_type, DW_TAG_structure_type və DW_TAG_member kimi qeydlərdən istifadə edərək struktur adını, byte ölçüsünü və DW_AT_data_member_location vasitəsilə üzv mövqeyini çıxarır. Əldə olunan məlumatlar versiya və arxitektura üzrə strukturlaşdırılmış JSON fayllarına çevrilir.

Tədqiqatın əhatə sərhədi

Tədqiqat Android 9, 10, 11, 12, 13 və 14-ü əhatə edir. Android 15 tədqiqat başlayanda hələ buraxılmadığı üçün analizə daxil edilməyib. Bütün yığımlarda inkişaf və debug xüsusiyyətləri təmin edən AOSP eng build variantından istifadə olunub.

Mənbə həmçinin Android-in user, debug, eng və release kimi fərqli build konfiqurasiyalarının; arxitektura seçimlərinin və Samsung kimi OEM istehsalçılarının fərdiləşdirmələrinin struktur sayı, məlumat tipi və ölçülərində əlavə fərqlər yarada biləcəyini açıq şəkildə bildirir. Buna görə tədqiqatın nəticələri “bütün kommersiya Android telefonlarında byte səviyyəsində eyni strukturlar var” kimi şərh edilə bilməz.

Tədqiqatın Metodu və Nəticələri

Tədqiqat axını

Mənbə tədqiqatın səhifə 5-dəki Şəkil 1-i də bu məntiqi göstərir: AOSP versiyaları əvvəlcə yığılır və simvolları çıxarılır; sonra makro və mikro səviyyəli analizlər aparılır; nəticələr thread, heap və obyekt bərpasına təsirlərlə əlaqələndirilərək təkliflərə çevrilir.

Yığım mühiti

AOSP yığımları Linux əsaslı sistemdə həyata keçirilib. Mənbə təcrübə maşınını 13-cü nəsil Intel Core i9-13900KF prosessoru, 64 GB RAM və 4 TB yaddaşla təsvir edir. Hər versiya üçün ayrı və təmiz build environment qurulub; Git, Python, OpenJDK və Android Repo alətindən istifadə olunub. Mənbə hər versiya yığımının təxminən 4–5 saat çəkdiyini bildirir.

Niyə 34 struktur seçilib?

Yeni Android versiyalarındakı libart.so fayllarında 19.000-i aşan DWARF simvolu olduğuna görə bütün strukturları kriminalistik əhəmiyyət baxımından ayrı-ayrılıqda analiz etmək əvəzinə 34 kritik məlumat strukturuna fokuslanılıb. Bu strukturlar Android 8, 8.1 və 9-u dəstəkləyən DroidScraper adlı istifadəçi məkanı yaddaş kriminalistikası alətinin daha yeni versiyalara daşınması üçün hansı aşağı səviyyəli strukturların lazım olacağını araşdırmaqla müəyyən edilib.

Seçilmiş struktur qrupunda Runtime, Thread və Heap başda olmaqla thread enumeration, memory mapping və object recovery üçün lazım olan yardımçı strukturlar yer alır.

RQ1 — ART kitabxanasının ölçüsü necə dəyişdi?

Binary ölçüsü monoton şəkildə artmır. x86-64 üçün Android 10-dakı 147,36 MB dəyərindən Android 11-də 200,71 MB-a yüksəlib; mənbə bunu təxminən %36 artım kimi şərh edir. Android 13-də isə bütün arxitekturalarda nəzərəçarpacaq kiçilmə görünür. ARM64 nümunəsində Android 12-nin 177,09 MB-lıq faylı Android 13-də 89,76 MB-a düşür.

Tədqiqatçılar readelf ilə apardıqları araşdırmada Android 9–12-nin DWARF 4, Android 13 və 14-ün isə DWARF 5 istifadə etdiyini müəyyən ediblər. Mənbə DWARF 5-in məlumatın daha sıx paketlənməsinə töhfə verə biləcəyini bildirərkən binary ölçüsünün compiler flag, debug information miqdarı və optimizasiya seçimlərindən də təsirlənə biləcəyini xəbərdar edir. Buna görə təxminən 48% ölçü azalmasını təkbaşına ART funksiyasının itirilməsi kimi oxumaq düzgün deyil.

RQ2 — Debug simvollarının sayı necə dəyişdi?

ARM64 simvol sayı Android 9-dakı 15.698-dən Android 14-də 19.115-ə yüksəlib; mənbə bunu təxminən %22 artım kimi bildirir. Android 13-də qısamüddətli azalma görünsə də, Android 14 araşdırılan dövrün ən yüksək simvol sayına malikdir.

Buradakı mühüm nəticə odur ki, binary ölçüsü Android 13 və 14-də ciddi şəkildə azalsa da debug simvollarının sayı uzun müddətdə artır. Buna görə “fayl kiçildi, icra zamanı sadələşdi” nəticəsi çıxarıla bilməz. Mənbənin şərhi DWARF 5 kimi daha səmərəli kodlamanın zəngin debug məlumatını daha kiçik binary daxilində daşıya bilməsi istiqamətindədir.

RQ3 — 34 kritik strukturda neçə dəyişiklik tapıldı?

1067 dəyişikliyin 956-sı üzvlərin struktur daxilindəki mövqeyinin dəyişməsidir. Bu təxminən %89,60-a uyğun gəlir. Üzv əlavələri təxminən %6,37, üzv silinmələri təxminən %3,66 və bütöv struktur silinmələri təxminən %0,37-dir.

Ən intensiv dəyişiklik Android 9→10 keçidindədir. Daha sonra Android 11→12 keçidində ümumi dəyişiklik sayı 109-a qədər azalıb, lakin Android 12→13 və 13→14 dövrlərində yenidən nəzərəçarpacaq struktur hərəkətlilik müşahidə edilib.

Mənbə mətnindəki 355 və 201 rəqəmləri bütöv struktur silinmələrini cəmə daxil etmədiyi üçün yuxarıdakı cədvəl birbaşa mənbə Cədvəl II dəyərlərinə əsasən hazırlanıb.

Niyə Tək Bir Yaddaş Ofsetinin Dəyişməsi Kriminalistik Analizi Poza Bilər?

Yaddaş kriminalistikası alətləri çox vaxt məlumat strukturunun müəyyən üzvünə strukturun başlanğıcından sabit byte məsafəsi ilə daxil olur; Android yeniləməsi eyni üzvü başqa ofsetə daşıdıqda köhnə profil yanlış yaddaş mövqeyini oxuya bilər. Bu xəta thread siyahısının, heap pointer-ının və ya obyektin class məlumatının başlanğıc nöqtəsində yaranarsa, sonrakı pointer dereference əməliyyatları da yanlış zənciri izləyə və yüksək səviyyəli kriminalistik reconstruction əməliyyatı uğursuz ola bilər.

RQ4 — Runtime, Thread və Heap eyni şəkildə təkamül etmədi

Mənbə ART-ın üç mərkəzi strukturunun bir-birindən fərqli təkamül nümunəsi göstərdiyini bildirir.

Səhifə 9-dakı Şəkil 2 bu fərqi xüsusilə görünən edir: Thread strukturu Android 9→10 keçidində qəfil sıçrayış etdiyi halda Runtime daha dəyişkən böyümə xətti izləyir, Heap isə daha məhdud dəyişir. Tədqiqatçılar Android 10-dakı Thread böyüməsinin mühüm səbəblərindən biri kimi 4000 byte-dan çox yer tutan yeni interpreter_cache_ üzvünü göstərirlər.

Təsir skoru nəyi göstərir?

Tədqiqatçılar struktur dəyişikliyinin yalnız sayını deyil, intensivliyini göstərmək üçün 0 ilə 1 arasında təsir skoru hazırlayıblar. Skor üç elementi birlikdə qiymətləndirir: ofset dəyişikliyindən təsirlənən üzvlərin nisbəti, əlavə edilən və ya silinən üzvlərin ümumi üzvlərə nisbəti və struktur ölçüsündəki nisbi dəyişikliyin böyüklüyü.

Mənbə bu ölçünün qapalı-form tənliyini vermədiyi üçün burada yeni formula çıxarılmır. Səhifə 10-dakı Şəkil 3-ün istilik xəritəsində Runtime üçün Android 9→10 ofset dəyişmə təsiri 0,90 səviyyəsindədir. Thread eyni keçiddə yüksək dəyişiklik göstərdiyi halda sonrakı versiyalarda əksər ölçülərdə daha aşağı təsir skorlarına enir. Heap ümumilikdə daha aşağı və sabit təsir səviyyələrində qalır.

RQ5 — Thread enumeration necə təsirlənir?

Bir Android prosesində thread-ləri tapmaq üçün Runtime strukturundan thread_list_ sahəsinə daxil olmaq və buradan ThreadList daxilindəki ikiqat bağlı thread zəncirini izləmək lazımdır. Lakin thread_list_ sahəsinin ofseti Android 9-dan 14-ə belə dəyişib:

Burada birtərəfli, proqnozlaşdırıla bilən artım və ya azalma nümunəsi yoxdur. Əvvəlki versiyanın sabit dəyərini yeni versiyaya daşımaq təhlükəsiz deyil.

Thread identifikatorunun həllində istifadə olunan name_ və tid_ kimi sahələrin də araşdırılan versiyaların təxminən yarısında mövqe dəyişdirdiyi bildirilir. tls_32bit_sized_values daxilindəki park_state_ sahəsi Android 10-da ofset 60-da meydana çıxıb, Android 14-də ofset 44-ə daşınıb.

Heap analizi necə təsirlənir?

Heap analizinin əsas giriş nöqtələrindən biri yenə Runtime daxilindəki heap_ pointer-ıdır. Tədqiqatda bu sahənin Android 9→14 boyunca ardıcıl olaraq 448 → 400 → 392 → 416 → 512 → 512 ofsetlərində yerləşdiyi göstərilib.

Heap daxilindəki region_space_ sahəsi də Android 9-dakı 728 ofsetindən Android 14-də 840 ofsetinə daşınıb. RegionSpace daxilində bölgə sayının anlaşılmasında istifadə olunan num_regions_ kimi kritik sahələrin də bir neçə dəfə yenidən yerləşdirildiyi bildirilir.

Bu dəyişikliklər yalnız “bir ünvanı yenilə” problemi deyil; thread-lər Thread Local Allocation Buffer istifadə edərək heap bölgələrinə obyekt ayıra bildiyinə görə thread, heap və object-recovery məlumatları bir-biri ilə bağlıdır.

Obyekt reconstruction niyə daha çətin oldu?

Tətbiq səviyyəli dəlillər çox vaxt siniflərin instance-ları və bu obyektlərdəki instance və ya static field-lar şəklində yaddaşda yerləşir. Buna görə Android obyektini düzgün class strukturuna bağlamaq və field-larını həll etmək istifadəçi məkanı kriminalistik analizinin mərkəzindədir.

Android 9–12 dövründə Object və Class ilə əlaqəli sahələrdə ofset dəyişiklikləri müşahidə olunarkən Android 12→13 keçidində daha əsaslı dəyişiklik baş verib: tədqiqat Object və Class daxil olmaqla bəzi əsas strukturların libart.so daxilindən silindiyini bildirir. Bu, köhnə analiz kodunun yalnız yeni ofset cədvəli ilə davam etməsini çətinləşdirir.

Android 10-dakı JIT dəyişikliyi niyə yalnız struktur ölçüsündən daha vacibdir?

Mənbə Android 9→10 dövründə profiler-əsaslı Just-In-Time compilation dəstəyi ilə birlikdə JitCodeCache və ProfilingInfo kimi strukturların meydana çıxdığını bildirir.

Android 9 və əvvəlki quruluşlarda DexFile instance-ları OATFile-lar daxilində olur və OatFileManager vasitəsilə əlçatan idi. DroidScraper kimi alətlər bu əlaqədən istifadə edərək DexFile nümunələrinə çata bilirdi.

Android 10-dan sonra OatFileManager tətbiqə xas OAT fayllarının eyni şəkildə meneceri olmaqdan çıxıb. Mənbə daha yeni versiyalarda tətbiq DexFile nümunələrinə çatmaq üçün aşağıdakı daha mürəkkəb əlaqə zəncirinin izlənməli olduğunu izah edir:

JitCodeCache → ProfilingInfo → ArtMethod → DexCache → DexFile

Bu nümunə tədqiqatın əsas mesajını güclü şəkildə göstərir: yeni Android versiyasında bütün ofsetləri düzgün bilmək belə köhnə alqoritmin işləməsinə zəmanət vermir; bəzən strukturlar arasındakı semantik əlaqə və giriş yolu da dəyişir.

Ən geniş nəticə: %73,2 struktur mövqe dəyişikliyi

Müzakirə bölməsində tədqiqatçılar versiyalar arasında mövcudluğunu davam etdirən bütün struktur üzvlərini birlikdə qiymətləndiriblər. Bu üzvlərin %73,2-si Android 9–14 aralığında ən azı bir dəfə fərqli ofsetə daşınıb.

Runtime-ın %89,4-lük göstəricisi xüsusilə mühümdür; çünki Runtime bir çox digər struktura girişin mərkəzində yerləşir. Belə mərkəzi strukturdakı genişmiqyaslı mövqe dəyişikliyi tək bir plugin və ya parser funksiyasından daha geniş kod zəncirinə təsir göstərə bilər.

Android Yaddaş Kriminalistikası Alətlərində Yalnız Ofsetləri Yeniləmək Kifayətdirmi?

Xeyr. Tədqiqat göstərir ki, bəzi Android keçidlərində yalnız struktur üzvlərinin mövqeyi deyil, strukturların mövcudluğu, kitabxanalar arasındakı yeri və digər strukturlara giriş yolları da dəyişir. Buna görə yeni versiyaya uyğunlaşdırma bəzən sabit ofset cədvəlini yeniləməkdən daha çoxunu; versiya-fərqində olan parsing, alternativ discovery yolları və semantik əlaqələri yenidən qura bilən analiz texnikalarını tələb edir.

Müəlliflərin təklif etdiyi hibrid yanaşma

Tədqiqatçılar simvol-əsaslı kriminalistikadan tamamilə imtina edilməsinə qarşıdırlar. Simvollar strukturların mənasını və mənbə kodu ilə izlənə bilənliyini təmin etdiyinə görə kriminalistik yoxlama baxımından dəyərlidir. Problem onların təkbaşına istifadə edilməsidir.

Təklif olunan gələcək alət arxitekturasında bir neçə bacarığın birlikdə istifadəsi ön plana çıxır:

• Struktur təriflərini Android versiyasına görə seçən versiya-fərqində olan parsing.
• Sabit layout ilə parser məntiqini bir-birindən ayıran modul arxitektura.
• Versiya-spesifik struktur xəritələri ilə ümumi analiz kodunun birlikdə istifadəsi.
• Runtime və Thread kimi kritik giriş nöqtələri üçün birdən çox kəşf yolu.
• Simvol uğursuz olduqda memory scanning və ya davranışsal pattern tracing kimi ehtiyat üsullar.
• Strukturların kod daxilində necə istifadə olunduğunu analiz edən symbolic execution.
• Gələcəkdə directed symbolic execution ilə memory-access-pattern analizinin birlikdə istifadəsi.

Mənbə Seance adlı əvvəlki proof-of-concept tədqiqatını simvolik icranın potensialına nümunə kimi göstərir; lakin global variable referanslarındakı bəzi dəyişiklikləri aşkar edə bilməməsi kimi problemləri də açıq şəkildə qeyd edir. Buna görə symbolic execution da təkbaşına qüsursuz həll kimi təqdim edilmir.

Tədqiqatın dəstəklədiyi nəticələr

• Android 9–14 arasında ART strukturlarının daxili yerləşimləri əhəmiyyətli dərəcədə dəyişir.
• 34 kritik strukturda ən geniş yayılmış dəyişiklik növü üzv ofsetlərinin yenidən yerləşdirilməsidir.
• Runtime, Thread və Heap eyni təkamül nümunəsini göstərmir.
• Thread enumeration, heap analysis və object reconstruction bu dəyişikliklərdən birbaşa təsirlənir.
• Static symbol/profile yanaşmasını təkbaşına davam etdirmək getdikcə daha çox texniki xidmət tələb edir.
• Struktur əlaqələri dəyişdikdə yalnız ofset cədvəllərinin yenilənməsi kifayət etməyə bilər.
• Yoxlanıla bilən simvolik məlumatı daha uyğunlaşa bilən üsullarla birləşdirən hibrid dizayn tədqiqatçıların təklif etdiyi istiqamətdir.

Tədqiqatın dəstəkləmədiyi nəticələr

• Bütün kommersiya Android telefonlarının araşdırılan AOSP eng yığımları ilə eyni yaddaş layout-una malik olduğu göstərilməyib.
• Samsung və ya digər OEM-lərin fərdiləşdirilmiş firmware-ləri birbaşa müqayisə edilməyib.
• Android 15 və sonrakı versiyalar təcrübə əhatəsinə daxil edilməyib.
• Təklif olunan hibrid üsulların hamısının production səviyyəsində işləyən vahid yeni kriminalistik alətdə üstünlüyü təcrübə ilə göstərilməyib.
• Symbolic execution bütün struktur dəyişikliklərini qüsursuz aşkarlayan həll kimi sübut edilməyib.
• Tədqiqat real məhkəmə işində dəlilin qəbuledilənliyini ölçən hüquqi doğrulama təcrübəsi deyil.

Metodoloji şərh sərhədləri

Tədqiqatın güclü tərəfi eyni AOSP versiyalarının dörd arxitekturada yenidən yığılaraq müqayisə edilməsi və struktur məlumatının birbaşa DWARF qeydlərindən çıxarılmasıdır. Bu, versiyalararası dəyişikliyi sistemli şəkildə ölçməyə imkan verir.

Bununla yanaşı, bütün yığımlar AOSP eng konfiqurasiyasına əsaslanır. Mənbənin özü Android-in fərqli build rejimlərinin və OEM fərdiləşdirmələrinin strukturların sayına, tipinə və ölçülərinə təsir göstərə biləcəyini bildirir. Buna görə sahə cihazlarında qarşılaşıla biləcək müxtəliflik bu tədqiqat dizaynından daha geniş ola bilər.

Bundan əlavə, mikro səviyyəli struktur müqayisəsi əsasən x86-64 üzərində həyata keçirilib. Tədqiqatçılar bu seçimi eyni Android versiyası daxilində simvol sayı və struktur əlaqələrinin arxitekturalar arasında çox oxşar olması ilə əsaslandırırlar; lakin mənbə alignment səbəbli real yaddaş layout fərqlərinin ola biləcəyini də qəbul edir.

Android 15 tədqiqat başlayanda yayımlanmadığından analiz Android 14-də başa çatır. Nəticələr Android-in sonrakı versiyalarının hansı strukturları dəyişəcəyinə dair qəti proqnoz kimi istifadə edilməməlidir.

Mənbə və Metod Qeydi

Orijinal tədqiqat: Exploring Runtime Evolution in Android: A Cross-Version Analysis and Its Implications for Memory Forensics

Müəlliflər: Babangida Bappah, Lauren G Bristol, Lamine Noureddine, Sideeq Bello, Umar Farooq və Aisha Ali-Gombe

Qurum: Louisiana State University, USA

Nəşr növü: Resenziyalı konfrans məruzəsi.

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

Nəşr ili: 2025.

Səhifələr: 349–362.

Nəşriyyat: IEEE Computer Society.

DOI: 10.1109/RAID67961.2025.00040

arXiv versiyası: arXiv:2512.18517; arXiv yüklənmə tarixi 20 Dekabr 2025.

Əsas tədqiqat növü: Android Runtime məlumat strukturlarının versiyalararası empirik və hesablama ölçmə analizi.

Araşdırılan Android versiyaları: Android 9, 10, 11, 12, 13 və 14.

Araşdırılan arxitekturalar: ARM32, ARM64, x86-32 və x86-64.

Build konfiqurasiyası: AOSP eng build.

Əsas binary: libart.so.

Struktur məlumat mənbəyi: DWARF sazlama məlumatı.

Parser: ART-ın C++ strukturuna xüsusi hazırlanmış, pyelftools istifadə edən xüsusi ayrışdırıcı.

Analiz üsulları: Cross-Version Binary Profiling və Symbol-Based Structural Evolution Analysis.

Təfərrüatlı mikro analiz əhatəsi: Yaddaş kriminalistikası baxımından kritik 34 ART məlumat strukturu.

Məlumat/repository vəziyyəti: Mənbə tədqiqat Android 9–14 üçün çıxarılan runtime structure məlumatlarının və tədqiqat framework-ünün ictimaiyyətə açıq tədqiqat repository-sində saxlandığını bildirir.

Maliyyələşdirmə: Tədqiqat Department of Homeland Security (DHS) nəzdindəki Criminal Investigations and Network Analysis Center (CINA), Grant No. E206378P tərəfindən dəstəklənib.

Maraqlar toqquşması: Təqdim edilən PDF-də ayrıca maraqlar toqquşması bəyanatı aşkar edilməyib.

Müəllif töhfələri: Təqdim edilən PDF-də ayrıca CRediT/müəllif töhfələri bölməsi verilməyib.

Lisenziya: Təqdim edilən PDF daxilində etibarlı şəkildə doğrulana bilən açıq lisenziya növü tapılmadığından qorunan mətn və orijinal şəkillərin yenidən istifadəsində açıq lisenziya fərz edilməyib. Verianla mətninin təqdimatı elmi faktlar, üsullar və bildirilən kəmiyyət nəticələri üzərindən müstəqil şəkildə qurulub.

Mənbədaxili kəmiyyət uyğunsuzluğu: Cədvəl II Android 9→10 üçün 356 və Android 12→13 üçün 204 ümumi dəyişiklik göstərdiyi halda ətrafdakı mətn müvafiq olaraq 355 və 201 verir. Fərq mətndəki hesablamanın bütöv struktur silinmələrini cəmdən kənarda saxlamasından qaynaqlanır. Verianla cədvəllərində mənbə Cədvəl II-nin kateqoriya üzrə dəyərləri qorunub.

Əsas şərh sərhədi: Tədqiqat AOSP eng build-lərini və Android 9–14 dövrünü araşdırır. OEM firmware müxtəlifliyi, digər build profilləri və Android 15-dən sonrakı strukturlar birbaşa ölçülməyib. Təklif olunan hibrid kriminalistik analiz yanaşması gələcək alət inkişafı üçün elmi təklifdir; bu tədqiqatda bütün komponentləri bir araya gətirən yeni production alətinin sahə uğuru sınaqdan keçirilməyib.

Müəllif hüququ və təqdimat üsulu: Mənbənin orijinal cümlələri, abzas sırası və ya şəkil dizaynları yenidən yaradılmayıb. Verianla mətni; mənbədə bildirilən struktur dəyişiklikləri, binary və symbol ölçmələri, ofset dəyərləri, metod addımları və şərh sərhədləri çıxarılaraq müstəqil öyrədici arxitektura ilə hazırlanıb.