Utafiti huu unapima kwa utaratibu jinsi Android Runtime ilivyobadilika kimuundo kutoka Android 9 hadi Android 14 na athari za mabadiliko hayo kwa forensiki ya kumbukumbu ya user space. Android Runtime (ART) ni safu ya msingi ya programu inayosaidia utekelezaji wa programu za Android na kusimamia kazi za runtime kama uundaji wa object, mzunguko wa maisha wa thread na usimamizi wa kumbukumbu. Watafiti walijenga matoleo sita ya Android kutoka vyanzo vya AOSP katika usanifu manne—ARM32, ARM64, x86-32 na x86-64—kisha wakatoa taarifa za debug za DWARF kutoka faili ya libart.so katika kila build kwa parser maalumu na kulinganisha majina ya structure, ukubwa wa structure, members na memory offsets kati ya matoleo.

Matokeo muhimu zaidi ya utafiti ni kwamba kuwepo kwa structure au field yenye jina lilelile katika toleo linalofuata la Android hakumaanishi kuwa itakuwa katika eneo lilelile la kumbukumbu. %73,2 ya members za structure zilizobaki kuwepo katika matoleo mbalimbali zilibadilisha offset angalau mara moja. %89,4 ya members katika structure ya Runtime na %64,7 ya members zinazohusiana na usimamizi wa thread zilihamishwa angalau mara moja. Mabadiliko haya yanaweza kusababisha zana za forensiki zinazotegemea ufafanuzi tuli wa structure na offsets zisizobadilika kusoma data isiyo sahihi katika toleo jipya la Android au kushindwa kufanya kazi kabisa.

Kwa structures 34 muhimu za forensiki zilizochunguzwa kati ya Android 9–14, Jedwali II linaonyesha jumla ya mabadiliko 1067 ya kimuundo: mabadiliko 956 ya offset, members 68 wapya, members 39 walioondolewa na kuondolewa kwa structures nne nzima. Takriban %89,6 ya mabadiliko hayo ni kubadilika tu kwa nafasi ya members ndani ya structure. Kwa hiyo hata mabadiliko madogo yanayoonekana katika source code yanaweza kuvuruga dhana zinazotumiwa na zana inayotafsiri memory image.

Utafiti haupendekezi kuachana na mbinu zinazotegemea symbols. Kinyume chake, unatetea kuhifadhi uwezo wa kuthibitisha na kufuatilia unaotolewa na symbols, lakini kuuchanganya na parsing inayotambua toleo, uchimbaji wa structure kiotomatiki, symbolic execution, uchambuzi wa memory-access patterns na njia mbadala za discovery. Kwa kuwa matokeo yanategemea build za AOSP eng kwa Android 9–14, marekebisho ya watengenezaji wa OEM, build modes tofauti na matoleo baada ya Android 15 hayakujaribiwa moja kwa moja.

Kwa nini forensiki ya kumbukumbu si uchunguzi wa diski pekee?

Programu inapokuwa inaendeshwa, taarifa muhimu haipatikani tu katika hifadhi ya kudumu. Hali za programu zilizo wazi, mwingiliano wa muda wa mtumiaji, objects zilizotatuliwa, runtime metadata na taarifa nyingine ambazo bado hazijaandikwa kwenye diski zinaweza kuwepo ndani ya RAM. Forensiki ya kumbukumbu ya user space hujaribu hasa kuelewa data hizi za muda zinazohusiana na programu.

Hata hivyo, katika raw memory image maana ya mlolongo fulani wa byte haijulikani moja kwa moja. Zana ya uchambuzi lazima ijue structure ya Runtime, Thread, Heap, Class au structure nyingine ya C++ inaundwa na members gani na kila member iko byte ngapi kutoka mwanzo wa structure. Umbali huu huitwa memory offset.

Kwa mfano, ikiwa zana inadhani anwani ya orodha ya thread iko katika offset fulani ndani ya structure ya Runtime, field hiyo ikihama kwa makumi kadhaa ya byte katika toleo jipya la Android kwa sababu members wengine wameongezwa, zana ya zamani inaweza kusoma field nyingine badala ya orodha ya thread. Katika forensiki ya kumbukumbu, kutatua anwani moja vibaya kunaweza kuathiri mnyororo mzima wa objects unaofuata.

Android Runtime (ART) ni Nini na Kwa Nini ni Muhimu kwa Forensiki ya Kumbukumbu?

Android Runtime (ART) ni mfumo wa runtime unaosimamia ugawaji wa kumbukumbu, maisha ya object, usimamizi wa thread, michakato ya garbage collection na structures nyingi za ndani zinazohusiana na utekelezaji wa code ya programu wakati programu za Android zinaendeshwa. Kwa kuwa forensiki ya kumbukumbu ya user space inaweza kujenga upya thread, maeneo ya heap na application objects kwa kutegemea pointer, members na mahusiano katika structures hizi, mabadiliko ya kimuundo ya ART kati ya matoleo yanaathiri moja kwa moja uaminifu wa zana za forensiki.

Kwa nini mpito kutoka Dalvik hadi ART ulikuwa muhimu?

Usanifu wa runtime wa Android umebadilika kwa kiasi kikubwa kadiri muda ulivyopita. Mpito kutoka kipindi cha Dalvik hadi ART haukuwa mabadiliko ya jina tu; namna ya kutekeleza application code, ugawaji wa kumbukumbu, garbage collection na internal data structures pia zilibadilika. Pamoja na ART, memory allocators kama RosAlloc na, katika matoleo ya baadaye, structures kama Region Space Allocation zikawa muhimu kwa uchambuzi wa forensiki.

RosAlloc hugawa heap memory katika maeneo yenye slots kwa objects za ukubwa maalumu. Objects kubwa zaidi zinaweza kuhamishwa katika maeneo tofauti kama Large Object Space. Baada ya Android 8, Concurrent Copying na Region Space Allocation kuwa sehemu za msingi kulifanya iwe vigumu kuhamisha moja kwa moja mbinu za zamani za memory recovery kwenda katika matoleo mapya.

Suala kuu hapa ni kwamba ingawa Android inadumisha framework ya jumla ya ART, internal structures zake hazibaki zisizobadilika. Kazi ileile inaweza kuendelea kuwepo kwa miaka, lakini structure, pointer chain au nafasi ya member inayotumiwa kuifikia inaweza kubadilika.

Maswali matano ya utafiti

Kwa nini architectures nne zilichunguzwa?

Watafiti walichunguza matoleo ya 32-bit na 64-bit ya familia za ARM na x86: ARM32, ARM64, x86-32 na x86-64. Sababu ni kwamba si toleo la Android pekee, bali pia processor architecture inaweza kuathiri pointer size, alignment na memory layout.

Hata hivyo, ilibainika kwamba idadi ya symbols katika architectures nne ndani ya toleo lilelile la Android ilikuwa karibu sana. Kwa mfano, kwa Android 14 idadi ya symbols ni 19.115 katika ARM64, 19.100 katika x86-64, 19.107 katika ARM32 na 19.097 katika x86-32. Kwa hiyo watafiti walitumia x86-64 kama architecture wakilishi katika ulinganisho wa kina wa micro-structure. Uamuzi huu haumaanishi kwamba memory layouts zote za architecture ni sawa katika kiwango cha byte; chanzo kinasisitiza kwamba tofauti za alignment zinaweza kuathiri memory layout.

Forensiki ya Kumbukumbu Inayotegemea Symbols ni Nini?

Forensiki ya kumbukumbu inayotegemea symbols au profiles ni mbinu inayotafsiri memory image kwa kutoa majina, ukubwa, members na member offsets za data structures kutoka taarifa za debug zinazozalishwa na compiler. Mbinu hii hutoa uwezo mkubwa wa kufuatilia na kuthibitisha; lakini structure definitions zinapobadilika katika kila toleo la Android, profiles na parsing code inayozitumia lazima zisasishwe kila mara.

DWARF inafanya nini hapa?

DWARF ni format ya debug information inayoweza kubeba taarifa za structure na variable katika compiled binaries kwa madhumuni ya debugging. Utafiti hutumia taarifa za DWARF ndani ya libart.so kutoa majina ya C++ structures za ART, jumla ya ukubwa wa byte na nafasi za members ndani ya structure.

Kwa sababu ART hutumia sana C++ inheritance, template na object-oriented structures tata, imeelezwa kwamba mbinu ya kawaida ya dwarf2json haikukidhi mahitaji ya watafiti. Kwa hiyo parser maalumu inayotegemea pyelftools ilitengenezwa.

Parser hupitia Compilation Units na rekodi za Debugging Information Entry ndani ya DWARF; hutumia rekodi kama DW_TAG_class_type, DW_TAG_structure_type na DW_TAG_member kutoa jina la structure, ukubwa wa byte na, kupitia DW_AT_data_member_location, nafasi ya member. Taarifa zilizopatikana hubadilishwa kuwa faili za JSON zilizopangwa kwa kila toleo na architecture.

Mpaka wa wigo wa utafiti

Utafiti unahusisha Android 9, 10, 11, 12, 13 na 14. Android 15 haikujumuishwa katika uchambuzi kwa sababu haikuwa imetolewa wakati utafiti ulipoanza. Build zote zilitumia AOSP eng build variant inayotoa vipengele vya development na debug.

Chanzo pia kinaeleza wazi kwamba build configurations tofauti za Android kama user, debug, eng na release; architecture options na customizations za watengenezaji wa OEM kama Samsung zinaweza kuleta tofauti za ziada katika idadi, aina ya data na ukubwa wa structures. Kwa hiyo matokeo ya utafiti hayawezi kutafsiriwa kama “simu zote za kibiashara za Android zina structures zilezile katika kiwango cha byte”.

Mbinu na Matokeo ya Utafiti

Mtiririko wa utafiti

Kielelezo 1 katika ukurasa wa 5 wa utafiti chanzo pia kinaonyesha mantiki hii: matoleo ya AOSP hujengwa kwanza na symbols zake hutolewa; kisha uchambuzi wa macro na micro hufanyika; matokeo huhusishwa na athari kwa thread, heap na object recovery na kubadilishwa kuwa mapendekezo.

Mazingira ya build

AOSP builds zilifanywa kwenye mfumo unaotegemea Linux. Chanzo kinaeleza mashine ya majaribio kuwa na processor ya kizazi cha 13 Intel Core i9-13900KF, 64 GB RAM na 4 TB storage. Build environment tofauti na safi iliandaliwa kwa kila toleo; Git, Python, OpenJDK na Android Repo tool zilitumika. Chanzo kinaripoti kuwa kila version build ilichukua takriban 4–5 hours.

Kwa nini structures 34 zilichaguliwa?

Kwa kuwa faili za libart.so katika matoleo mapya ya Android zilikuwa na zaidi ya 19.000 DWARF symbols, badala ya kuchanganua kila structure moja kwa moja kwa umuhimu wa forensiki, utafiti ulilenga data structures 34 muhimu. Structures hizi zilitambuliwa kwa kuchunguza ni low-level structures zipi zingehitajika ili kuhamisha zana ya user-space memory forensics iitwayo DroidScraper, inayounga mkono Android 8, 8.1 na 9, kwenda matoleo mapya zaidi.

Kundi la structures zilizochaguliwa linajumuisha hasa Runtime, Thread na Heap, pamoja na auxiliary structures zinazohitajika kwa thread enumeration, memory mapping na object recovery.

RQ1 — Ukubwa wa maktaba ya ART ulibadilikaje?

Ukubwa wa binary hauongezeki kwa mtindo wa monotoniki. Kwa x86-64, uliongezeka kutoka 147,36 MB katika Android 10 hadi 200,71 MB katika Android 11; chanzo kinatafsiri hili kama ongezeko la takriban %36. Katika Android 13, kuna upungufu dhahiri katika architectures zote. Katika mfano wa ARM64, faili ya 177,09 MB ya Android 12 inapungua hadi 89,76 MB katika Android 13.

Katika uchunguzi wao kwa readelf, watafiti waligundua kwamba Android 9–12 hutumia DWARF 4, huku Android 13 na 14 zikitumia DWARF 5. Chanzo kinasema DWARF 5 inaweza kuchangia ufungashaji wa taarifa kwa msongamano mkubwa zaidi, huku kikionya kuwa ukubwa wa binary pia unaweza kuathiriwa na compiler flag, kiasi cha debug information na chaguo za optimization. Kwa hiyo si sahihi kutafsiri upungufu wa ukubwa wa karibu 48% pekee kama kupotea kwa functionality ya ART.

RQ2 — Idadi ya debug symbols ilibadilikaje?

Idadi ya symbols za ARM64 iliongezeka kutoka 15.698 katika Android 9 hadi 19.115 katika Android 14; chanzo kinaripoti hili kama ongezeko la takriban %22. Ingawa kuna upungufu wa muda mfupi katika Android 13, Android 14 ina idadi kubwa zaidi ya symbols katika kipindi kilichochunguzwa.

Matokeo muhimu hapa ni kwamba ingawa ukubwa wa binary ulipungua sana katika Android 13 na 14, idadi ya debug symbols iliongezeka kwa muda mrefu. Kwa hiyo hitimisho la “faili imepungua, runtime imerahisishwa” haliwezi kutolewa. Tafsiri ya chanzo ni kwamba encoding yenye ufanisi zaidi kama DWARF 5 inaweza kubeba taarifa nyingi za debug ndani ya binary ndogo zaidi.

RQ3 — Ni mabadiliko mangapi yalipatikana katika structures 34 muhimu?

Kati ya mabadiliko 1067, 956 ni mabadiliko ya nafasi ya members ndani ya structure. Hii ni takriban %89,60. Member additions ni takriban %6,37, member removals ni takriban %3,66 na kuondolewa kwa entire structures ni takriban %0,37.

Mabadiliko mengi zaidi yako katika mpito wa Android 9→10. Baadaye, katika mpito wa Android 11→12, jumla ya mabadiliko ilishuka hadi 109, lakini katika vipindi vya Android 12→13 na 13→14 kulionekana tena movement kubwa ya kimuundo.

Kwa sababu namba 355 na 201 katika maelezo ya chanzo hazijumuishi entire structure removals katika jumla, jedwali hapo juu limeandaliwa moja kwa moja kulingana na thamani za Jedwali II la chanzo.

Kwa Nini Mabadiliko ya Memory Offset Moja Yanaweza Kuvuruga Uchambuzi wa Forensiki?

Zana za forensiki ya kumbukumbu mara nyingi hufikia member fulani wa data structure kwa umbali thabiti wa byte kutoka mwanzo wa structure; Android update ikihamisha member huyo hadi offset nyingine, profile ya zamani inaweza kusoma eneo lisilo sahihi la kumbukumbu. Ikiwa kosa hili litatokea katika sehemu ya kuanzia ya thread list, heap pointer au class information ya object, shughuli zinazofuata za pointer dereference zinaweza pia kufuata mnyororo usio sahihi na high-level forensic reconstruction ikashindwa.

RQ4 — Runtime, Thread na Heap hazikubadilika kwa namna ileile

Chanzo kinaripoti kwamba structures tatu za msingi za ART zinaonyesha mifumo tofauti ya evolution.

Kielelezo 2 katika ukurasa wa 9 kinaonyesha tofauti hii hasa: structure ya Thread inafanya mkurupuko mkubwa katika mpito wa Android 9→10, Runtime ikifuata mstari wa ukuaji unaobadilika zaidi, huku Heap ikibadilika kwa kiwango kidogo zaidi. Watafiti wanaonyesha member mpya interpreter_cache_, inayochukua zaidi ya 4000 byte, kuwa mojawapo ya sababu muhimu za ukuaji wa Thread katika Android 10.

Impact score inaonyesha nini?

Watafiti walitengeneza impact score kati ya 0 na 1 ili kuonyesha si idadi tu bali pia ukubwa wa mabadiliko ya kimuundo. Score hiyo hutathmini vipengele vitatu pamoja: uwiano wa members walioathiriwa na offset change, uwiano wa members walioongezwa au kuondolewa dhidi ya total members, na ukubwa wa relative change katika structure size.

Kwa kuwa chanzo hakitoi closed-form equation ya kipimo hiki, hakuna formula mpya inayotolewa hapa. Katika heat map ya Kielelezo 3 kwenye ukurasa wa 10, athari ya offset change kwa Runtime katika Android 9→10 iko katika kiwango cha 0,90. Thread inaonyesha mabadiliko makubwa katika mpito huohuo, kisha katika matoleo yanayofuata hushuka hadi impact scores za chini katika vipimo vingi. Heap kwa ujumla hubaki katika viwango vya chini na thabiti vya athari.

RQ5 — Thread enumeration inaathiriwaje?

Ili kupata thread katika Android process, ni lazima kutoka structure ya Runtime kufikia field ya thread_list_ na kutoka hapo kufuata doubly linked thread chain ndani ya ThreadList. Hata hivyo, offset ya field ya thread_list_ imebadilika kutoka Android 9 hadi 14 kama ifuatavyo:

Hakuna pattern ya ongezeko au upungufu wa mwelekeo mmoja inayoweza kutabirika hapa. Si salama kuhamisha thamani thabiti ya toleo lililotangulia kwenda toleo jipya.

Imeelezwa pia kwamba fields kama name_ na tid_ zinazotumiwa kutatua thread identity zimebadilisha nafasi katika takriban nusu ya matoleo yaliyochunguzwa. Ndani ya tls_32bit_sized_values, field ya park_state_ ilionekana katika offset 60 kwenye Android 10 na kuhamia offset 44 kwenye Android 14.

Heap analysis inaathiriwaje?

Moja ya entry points kuu za heap analysis tena ni ndani ya Runtime, pointer ya heap_. Utafiti unaonyesha kuwa field hii ilikuwa katika offsets 448 → 400 → 392 → 416 → 512 → 512 mtawalia katika Android 9→14.

Field ya region_space_ ndani ya Heap pia imehamia kutoka offset 728 katika Android 9 hadi offset 840 katika Android 14. Inaelezwa kwamba fields muhimu kama num_regions_ zinazotumiwa kuelewa idadi ya regions ndani ya RegionSpace pia zimehamishwa mara nyingi.

Mabadiliko haya si tatizo la “sasisha anwani moja” tu; kwa kuwa thread zinaweza kutumia Thread Local Allocation Buffer kugawa objects katika heap regions, taarifa za thread, heap na object-recovery zimeunganishwa.

Kwa nini object reconstruction imekuwa ngumu zaidi?

Ushahidi wa kiwango cha application mara nyingi hukaa kwenye kumbukumbu katika mfumo wa instances za classes na instance au static fields ndani ya objects hizi. Kwa hiyo, kuhusisha Android object na class structure sahihi na kutatua fields zake ni jambo la msingi katika user-space forensic analysis.

Wakati offset changes zilionekana katika fields zinazohusiana na Object na Class katika kipindi cha Android 9–12, mabadiliko ya msingi zaidi yalitokea katika mpito wa Android 12→13: utafiti unaripoti kwamba baadhi ya structures za msingi, ikiwemo Object na Class, ziliondolewa kutoka libart.so. Hili linafanya iwe vigumu kwa old analysis code kuendelea kwa kutumia offset table mpya pekee.

Kwa nini mabadiliko ya JIT katika Android 10 ni muhimu zaidi kuliko structure size pekee?

Chanzo kinaeleza kwamba katika kipindi cha Android 9→10, structures kama JitCodeCache na ProfilingInfo zilijitokeza pamoja na profiler-based Just-In-Time compilation support.

Katika mipangilio ya Android 9 na kabla yake, DexFile instances zilipatikana ndani ya OATFiles na zingeweza kufikiwa kupitia OatFileManager. Zana kama DroidScraper ziliweza kutumia uhusiano huu kufikia DexFile instances.

Baada ya Android 10, OatFileManager haikuendelea kuwa manager wa application-specific OAT files kwa namna ileile. Chanzo kinaeleza kwamba katika matoleo mapya zaidi, ili kufikia application DexFile instances, mnyororo huu mgumu zaidi wa mahusiano lazima ufuatwe:

JitCodeCache → ProfilingInfo → ArtMethod → DexCache → DexFile

Mfano huu unaonyesha kwa nguvu ujumbe mkuu wa utafiti: hata kujua offsets zote kwa usahihi katika toleo jipya la Android hakuhakikishi kwamba algorithm ya zamani itafanya kazi; wakati mwingine semantic relationship na access path kati ya structures pia hubadilika.

Matokeo mapana zaidi: %73,2 ya mabadiliko ya nafasi ya kimuundo

Katika sehemu ya mjadala, watafiti walitathmini pamoja members zote za structure zilizobaki kuwepo kati ya matoleo. %73,2 ya members hizi zilihamishwa hadi offset tofauti angalau mara moja kati ya Android 9–14.

Thamani ya %89,4 ya Runtime ni muhimu hasa kwa sababu Runtime iko katikati ya upatikanaji wa structures nyingi nyingine. Mabadiliko makubwa ya nafasi katika structure kuu kama hii yanaweza kuathiri mnyororo mpana wa code kuliko plugin au parser function moja.

Je, Kusasisha Offsets Pekee Kunatosha katika Zana za Forensiki ya Kumbukumbu ya Android?

Hapana. Utafiti unaonyesha kwamba katika baadhi ya mipito ya Android si nafasi ya members za structure pekee inayobadilika, bali pia uwepo wa structures, mahali zilipo kati ya libraries na njia za kufikia structures nyingine. Kwa hiyo, kuzoesha zana kwa toleo jipya wakati mwingine kunahitaji zaidi ya kusasisha fixed offset table; kunahitaji version-aware parsing, njia mbadala za discovery na mbinu za uchambuzi zinazoweza kujenga upya semantic relationships.

Mbinu ya hybrid iliyopendekezwa na waandishi

Watafiti hawakubaliani na kuachana kabisa na symbol-based forensics. Symbols ni muhimu kwa uthibitishaji wa forensiki kwa sababu hutoa maana ya structures na traceability kwa source code. Tatizo ni kuzitumia peke yake.

Katika usanifu wa zana wa siku zijazo uliopendekezwa, matumizi ya pamoja ya uwezo kadhaa yanasisitizwa:

• Version-aware parsing inayochagua structure definitions kulingana na toleo la Android.
• Modular architecture inayotenganisha fixed layout na parser logic.
• Matumizi ya pamoja ya version-specific structure maps na common analysis code.
• Njia nyingi za discovery kwa entry points muhimu kama Runtime na Thread.
• Backup methods kama memory scanning au behavioral pattern tracing wakati symbol inashindwa.
• Symbolic execution inayochanganua jinsi structures zinavyotumiwa ndani ya code.
• Katika siku zijazo, matumizi ya pamoja ya directed symbolic execution na memory-access-pattern analysis.

Chanzo kinatoa kazi ya awali ya proof-of-concept iitwayo Seance kama mfano wa uwezo wa symbolic execution; lakini pia kinaeleza wazi matatizo kama kutoweza kugundua baadhi ya mabadiliko katika global variable references. Kwa hiyo symbolic execution haijawasilishwa kama suluhisho kamili peke yake.

Hitimisho zinazoungwa mkono na utafiti

• Internal layouts za ART structures hubadilika kwa kiasi kikubwa kati ya Android 9–14.
• Katika structures 34 muhimu, aina ya mabadiliko inayotokea mara nyingi zaidi ni relocation ya member offsets.
• Runtime, Thread na Heap hazionyeshi pattern ileile ya evolution.
• Thread enumeration, heap analysis na object reconstruction zinaathiriwa moja kwa moja na mabadiliko haya.
• Kuendelea kutumia static symbol/profile approach pekee kunahitaji maintenance inayozidi kuongezeka.
• Mahusiano ya kimuundo yakibadilika, kusasisha offset tables pekee kunaweza kutotosha.
• Hybrid design inayochanganya symbolic information inayoweza kuthibitishwa na mbinu zinazoweza kubadilika ndiyo mwelekeo unaopendekezwa na watafiti.

Hitimisho ambazo utafiti hauungi mkono

• Haijaonyeshwa kwamba simu zote za kibiashara za Android zina memory layout ileile na AOSP eng builds zilizochunguzwa.
• Customized firmware za Samsung au OEM nyingine hazijalinganishwa moja kwa moja.
• Android 15 na matoleo ya baadaye hayakujumuishwa katika wigo wa majaribio.
• Ubora wa mbinu zote za hybrid zilizopendekezwa katika zana moja mpya ya production-level forensics haujaonyeshwa kimajaribio.
• Symbolic execution haijathibitishwa kuwa suluhisho lisilo na makosa linalogundua mabadiliko yote ya structure.
• Utafiti si legal validation experiment inayopima admissibility ya ushahidi katika kesi halisi ya mahakama.

Mipaka ya tafsiri ya kimetodolojia

Nguvu ya utafiti ni kwamba matoleo yale yale ya AOSP yalijengwa upya katika architectures nne na kulinganishwa, huku structural information ikitolewa moja kwa moja kutoka rekodi za DWARF. Hii huruhusu mabadiliko kati ya matoleo kupimwa kwa utaratibu.

Hata hivyo, build zote zinategemea AOSP eng configuration. Chanzo chenyewe kinaeleza kwamba build modes tofauti za Android na OEM customizations zinaweza kuathiri idadi, aina na ukubwa wa structures. Kwa hiyo diversity inayoweza kukutana nayo katika vifaa halisi inaweza kuwa pana zaidi kuliko design ya utafiti huu.

Zaidi ya hayo, micro-level structure comparison ilifanywa hasa kwenye x86-64. Watafiti wanahalalisha uchaguzi huu kwa kufanana sana kwa symbol count na structure relationships kati ya architectures ndani ya toleo lilelile la Android; lakini chanzo pia kinakubali kwamba real memory layout differences zinazotokana na alignment zinaweza kuwepo.

Kwa kuwa Android 15 haikuwa imetolewa wakati utafiti ulipoanza, uchambuzi unaishia Android 14. Matokeo hayapaswi kutumiwa kama prediction ya uhakika kuhusu structures gani zitabadilishwa katika matoleo yajayo ya Android.

Maelezo ya Chanzo na Mbinu

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

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

Taasisi: Louisiana State University, USA

Aina ya uchapishaji: Makala ya konferensi iliyopitiwa na wenzao.

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

Mwaka wa uchapishaji: 2025.

Kurasa: 349–362.

Mchapishaji: IEEE Computer Society.

DOI: 10.1109/RAID67961.2025.00040

Toleo la arXiv: arXiv:2512.18517; tarehe ya kupakiwa arXiv 20 Desemba 2025.

Aina kuu ya utafiti: Uchambuzi wa empirical na computational measurement wa Android Runtime data structures kati ya matoleo.

Matoleo ya Android yaliyochunguzwa: Android 9, 10, 11, 12, 13 na 14.

Architectures zilizochunguzwa: ARM32, ARM64, x86-32 na x86-64.

Build configuration: AOSP eng build.

Binary kuu: libart.so.

Chanzo cha structural data: DWARF debug information.

Parser: Parser maalumu iliyotengenezwa kwa C++ structure ya ART na inayotumia pyelftools.

Mbinu za uchambuzi: Cross-Version Binary Profiling na Symbol-Based Structural Evolution Analysis.

Wigo wa detailed micro analysis: ART data structures 34 muhimu kwa memory forensics.

Hali ya data/repository: Utafiti chanzo unaeleza kwamba runtime structure information iliyotolewa kwa Android 9–14 na research framework zinahifadhiwa katika public research repository.

Ufadhili: Utafiti uliungwa mkono na Criminal Investigations and Network Analysis Center (CINA) ndani ya Department of Homeland Security (DHS), Grant No. E206378P.

Mgongano wa maslahi: Hakuna statement tofauti ya mgongano wa maslahi iliyogunduliwa katika PDF iliyotolewa.

Michango ya waandishi: Hakuna sehemu tofauti ya CRediT/michango ya waandishi iliyotolewa katika PDF iliyotolewa.

Leseni: Kwa kuwa hakuna aina ya open license iliyoweza kuthibitishwa kwa kuaminika ndani ya PDF iliyotolewa, open license haikudhuriwa kuwepo katika matumizi tena ya protected text na original figures. Maelezo ya Verianla yamejengwa kwa kujitegemea kupitia scientific facts, methods na reported quantitative results.

Kutolingana kwa kiasi ndani ya chanzo: Jedwali II linaonyesha jumla ya mabadiliko 356 kwa Android 9→10 na 204 kwa Android 12→13, huku maelezo yanayozunguka yakitoa 355 na 201 mtawalia. Tofauti hiyo inatokana na hesabu katika maelezo kuacha entire structure removals nje ya jumla. Katika majedwali ya Verianla, category-based values za Jedwali II la chanzo zimehifadhiwa.

Mpaka mkuu wa tafsiri: Utafiti unachunguza AOSP eng builds na kipindi cha Android 9–14. OEM firmware diversity, build profiles nyingine na structures baada ya Android 15 hazijapimwa moja kwa moja. Hybrid forensic analysis approach iliyopendekezwa ni pendekezo la kisayansi kwa maendeleo ya zana za baadaye; field success ya production tool mpya inayounganisha components zote haikujaribiwa katika utafiti huu.

Hakimiliki na mbinu ya uwasilishaji: Sentensi asilia, mpangilio wa aya au figure designs za chanzo hazijazalishwa upya. Maandishi ya Verianla yamejengwa katika independent educational architecture kwa kutoa structural changes, binary na symbol measurements, offset values, method steps na interpretation limits zilizoripotiwa katika chanzo.