Бул изилдөө Android 9 версиясынан Android 14 версиясына чейин Android Runtime түзүмү кандай өзгөргөнүн жана бул өзгөрүүлөр колдонуучу мейкиндигиндеги эс-тутум криминалистикасына кандай таасир этерин системалуу түрдө өлчөйт. Android Runtime (ART) — Android колдонмолорунун аткарылышын колдогон; объект түзүү, thread жашоо цикли жана эс-тутумду башкаруу сыяктуу аткаруу учурундагы функцияларды башкарган негизги программалык катмар. Изилдөөчүлөр Androidдин алты версиясын ARM32, ARM64, x86-32 жана x86-64 болуп төрт архитектурада AOSP булактарынан курап, ар бир build ичиндеги libart.so файлынын DWARF debug маалыматын атайын parser менен чыгарып, түзүм аттарын, түзүм өлчөмдөрүн, мүчөлөрдү жана эс-тутум офсеттерин версиялар боюнча салыштырышкан.

Изилдөөнүн эң маанилүү жыйынтыгы — кандайдыр бир түзүм же талаа кийинки Android версиясында ошол эле ат менен бар болушу анын эс-тутумда ошол эле жерде турарын билдирбейт. Версиялар бою сакталып калган түзүм мүчөлөрүнүн %73,2 бөлүгү кеминде бир жолу офсетин өзгөрткөн. Runtime түзүмүндөгү мүчөлөрдүн %89,4 бөлүгү, thread башкарууга байланышкан мүчөлөрдүн болсо %64,7 бөлүгү кеминде бир жолу кайра жайгаштырылган. Мындай өзгөрмөлүүлүк статикалык түзүм аныктамаларына жана туруктуу офсеттерге таянган криминалистикалык талдоо куралдары жаңы Android версиясында туура эмес маалымат окушуна же таптакыр иштебей калышына алып келиши мүмкүн.

Android 9–14 аралыгында каралган 34 маанилүү криминалистикалык түзүм үчүн II таблица жалпысынан 1067 түзүмдүк өзгөрүүнү көрсөтөт: 956 офсет өзгөрүүсү, 68 жаңы мүчө, 39 өчүрүлгөн мүчө жана төрт бүтүндөй түзүмдүн өчүрүлүшү. Өзгөрүүлөрдүн болжол менен %89,6 бөлүгү мүчөлөрдүн түзүм ичиндеги орду гана өзгөргөн учурлар. Ошондуктан көрүнүшү боюнча кичине булак-код өзгөрүүсү да эс-тутум сүрөтүн чечмелеген куралдын божомолдорун бузушу мүмкүн.

Изилдөө символго негизделген ыкмалардан баш тартууну сунуштабайт. Тескерисинче, символдор берген текшерилүүчүлүк жана из салуу мүмкүнчүлүгүн сактап, аны версияны эске алган parsing, автоматтык түзүм чыгаруу, symbolic execution, эс-тутумга кайрылуу үлгүлөрүн талдоо жана резервдик discovery жолдору менен айкалыштыруу керектигин жактайт. Жыйынтыктар Android 9–14 үчүн AOSP eng build түзүүлөрүнө негизделгендиктен, OEM өндүрүүчүлөрүнүн өзгөртүүлөрү, башка build режимдери жана Android 15 версиясынан кийинки версиялар түздөн-түз сыналган эмес.

Эмне үчүн эс-тутум криминалистикасы дискти гана текшерүү менен чектелбейт?

Колдонмо иштеп турганда маанилүү маалыматтар туруктуу сактагычта гана болбойт. Ачык колдонмо абалдары, убактылуу колдонуучу аракеттери, чечмеленген объекттер, аткаруу учурундагы metadata жана дискке али жазыла элек башка маалыматтар RAM ичинде болушу мүмкүн. Колдонуучу мейкиндигиндеги эс-тутум криминалистикасы өзгөчө колдонмого тиешелүү ушул убактылуу маалыматтарды түшүнүүгө аракет кылат.

Бирок чийки эс-тутум сүрөтүндө белгилүү бир byte тизмеги эмнени билдирери өзүнөн-өзү белгилүү эмес. Талдоо куралы Runtime, Thread, Heap, Class же башка C++ түзүмү кайсы мүчөлөрдөн турарын жана ар бир мүчө түзүмдүн башынан канча byte алыстыкта жайгашканын билиши керек. Бул аралык эс-тутум офсети деп аталат.

Мисалы, курал thread тизмесинин дареги Runtime түзүмүндө белгилүү бир офсетте турат деп кабыл алса, Androidдин жаңы версиясында башка мүчөлөр кошулуп, бул талаа бир нече ондогон byte жылганда эски курал thread тизмесинин ордуна башка талааны окушу мүмкүн. Эс-тутум криминалистикасында бир гана туура эмес даректи чечмелөө кийинки бүт объект чынжырына таасир этиши мүмкүн.

Android Runtime (ART) Деген Эмне жана Эс-Тутум Криминалистикасы Үчүн Эмне Үчүн Маанилүү?

Android Runtime (ART) — Android колдонмолору аткарылып жатканда эс-тутум бөлүштүрүүнү, объект өмүрүн, thread башкарууну, garbage collection процесстерин жана колдонмо кодунун аткарылышына байланышкан көптөгөн ички түзүмдөрдү башкарган аткаруу убактысынын системасы. Колдонуучу мейкиндигиндеги эс-тутум криминалистикасы бул түзүмдөрдөгү pointer, мүчө жана байланыштарга таянып thread лерди, heap аймактарын жана колдонмо объекттерин кайра кура алгандыктан, ARTтын версиялар арасындагы түзүмдүк өзгөрүшү криминалистикалык куралдардын ишенимдүүлүгүнө түздөн-түз таасир этет.

Dalvikтен ARTка өтүү эмне үчүн маанилүү болгон?

Androidдин аткаруу убактысы архитектурасы убакыт өткөн сайын олуттуу өзгөргөн. Dalvik доорунан ARTка өтүү атын гана өзгөртүү эмес эле; колдонмо кодунун аткарылыш жолу, эс-тутум бөлүштүрүү, garbage collection жана ички маалымат түзүмдөрү да өзгөргөн. ART менен бирге RosAlloc сыяктуу эс-тутум бөлүштүргүчтөр жана кийинки версияларда Region Space Allocation сыяктуу түзүмдөр криминалистикалык талдоо үчүн маанилүү болуп калган.

RosAlloc heap эс-тутумун белгилүү өлчөмдөгү объекттер үчүн slotтордон турган аймактарга бөлөт. Чоңураак объекттер болсо Large Object Space сыяктуу башка аймактарга жылдырылышы мүмкүн. Android 8 версиясынан кийин Concurrent Copying жана Region Space Allocation негизги механизмдерге айланганы эски эс-тутумду калыбына келтирүү ыкмаларын жаңы версияларга түз алып өтүүнү кыйындаткан.

Бул жердеги негизги маселе — Android жалпы ART алкагын сактаганы менен анын ички түзүмдөрү туруктуу калбайт. Бир эле функция жылдар бою сакталышы мүмкүн, бирок ага жетүү үчүн колдонулган түзүм, pointer чынжыры же мүчөнүн орду өзгөрүшү мүмкүн.

Изилдөөнүн беш изилдөө суроосу

Эмне үчүн төрт архитектура изилденген?

Изилдөөчүлөр ARM жана x86 үй-бүлөлөрүнүн 32-bit жана 64-bit версияларын тең карашкан: ARM32, ARM64, x86-32 жана x86-64. Мунун себеби Android версиясы гана эмес, процессор архитектурасы да pointer өлчөмүнө, alignment жана эс-тутум жайгашуусуна таасир этиши мүмкүн.

Ошол эле учурда бир Android версиясынын ичиндеги төрт архитектурада символдордун саны өтө жакын экени байкалган. Мисалы, Android 14 үчүн символ саны ARM64 архитектурасында 19.115, x86-64 архитектурасында 19.100, ARM32 архитектурасында 19.107 жана x86-32 архитектурасында 19.097. Ошондуктан изилдөөчүлөр деталдуу микро-түзүмдүк салыштырууда x86-64 архитектурасын өкүл архитектура катары колдонушкан. Бул чечим byte деңгээлиндеги бардык архитектуралык жайгашуулар бирдей дегенди билдирбейт; булак өзгөчө alignment айырмачылыктары эс-тутум жайгашуусуна таасир этиши мүмкүн экенин белгилейт.

Символго Негизделген Эс-Тутум Криминалистикасы Деген Эмне?

Символго негизделген же профильге негизделген эс-тутум криминалистикасы компилятор түзгөн debug маалыматынан маалымат түзүмдөрүнүн аттарын, өлчөмдөрүн, мүчөлөрүн жана мүчө офсеттерин чыгарып, эс-тутум сүрөтүн түшүндүрүүгө негизделген ыкма. Бул ыкма жогорку деңгээлдеги из салуу жана текшерүү мүмкүнчүлүгүн берет; бирок түзүм аныктамалары ар Android версиясында өзгөргөндө профилдер жана аларды колдонгон parsing коду дайыма жаңыланып турушу керек.

DWARF бул жерде эмне кылат?

DWARF — компиляцияланган бинардык файлдарда debug максаты үчүн түзүм жана өзгөрмө маалыматтарын сактай алган debug information форматы. Изилдөө libart.so ичиндеги DWARF маалыматын колдонуп ARTтын C++ түзүмдөрүнүн аттарын, жалпы byte өлчөмдөрүн жана мүчөлөрдүн түзүм ичиндеги орундарын чыгарат.

ART C++ inheritance, template жана татаал объектке багытталган түзүмдөрдү кеңири колдонгондуктан, стандарттык dwarf2json ыкмасы изилдөөчүлөрдүн муктаждыгын канааттандырбаганы айтылат. Ошондуктан pyelftools негизиндеги атайын parser иштелип чыккан.

Parser DWARF ичиндеги Compilation Unitтерди жана Debugging Information Entry жазууларын карап чыгат; DW_TAG_class_type, DW_TAG_structure_type жана DW_TAG_member сыяктуу жазууларды колдонуп түзүм атын, byte өлчөмүн жана DW_AT_data_member_location аркылуу мүчөнүн ордун чыгарат. Алынган маалыматтар версия жана архитектура боюнча түзүмдөштүрүлгөн JSON файлдарына айландырылат.

Изилдөөнүн камтуу чеги

Изилдөө Android 9, 10, 11, 12, 13 жана 14 версияларын камтыйт. Android 15 изилдөө башталганда чыга элек болгондуктан талдоого киргизилген эмес. Бардык build түзүүлөрүндө өнүктүрүү жана debug мүмкүнчүлүктөрүн берген AOSP eng build варианты колдонулган.

Булак ошондой эле Androidдин user, debug, eng жана release сыяктуу ар башка build конфигурациялары; архитектура тандоолору жана Samsung сыяктуу OEM өндүрүүчүлөрдүн өзгөртүүлөрү түзүмдөрдүн саны, маалымат түрү жана өлчөмдөрүндө кошумча айырмачылыктарды жаратышы мүмкүн экенин ачык белгилейт. Демек, изилдөө жыйынтыктарын “бардык коммерциялык Android телефондорунда byte деңгээлинде бирдей түзүмдөр бар” деп түшүндүрүүгө болбойт.

Изилдөөнүн Ыкмасы жана Жыйынтыктары

Изилдөө агымы

Булактагы изилдөөнүн 5-бетиндеги 1-сүрөт да ушул логиканы көрсөтөт: AOSP версиялары адегенде курулуп, символдору чыгарылат; андан кийин макро жана микро деңгээлдеги талдоолор жүргүзүлөт; жыйынтыктар thread, heap жана объект калыбына келтирүүгө болгон таасирлер менен байланышып, сунуштарга айландырылат.

Build чөйрөсү

AOSP build түзүүлөрү Linux негизиндеги системада аткарылган. Булак эксперименттик машинаны 13-муундагы Intel Core i9-13900KF процессору, 64 GB RAM жана 4 TB сактагыч менен сүрөттөйт. Ар бир версия үчүн өзүнчө жана таза build environment түзүлгөн; Git, Python, OpenJDK жана Android Repo куралы колдонулган. Булак ар бир версиянын build түзүүсү болжол менен 4–5 саатка созулганын билдирет.

Эмне үчүн 34 түзүм тандалган?

Жаңы Android версияларындагы libart.so файлдарында 19.000 санынан ашык DWARF символу болгондуктан, бардык түзүмдөрдү криминалистикалык мааниси боюнча өзүнчө талдоонун ордуна 34 маанилүү маалымат түзүмүнө көңүл бурулган. Бул түзүмдөр Android 8, 8.1 жана 9 версияларын колдогон DroidScraper аттуу колдонуучу мейкиндигиндеги эс-тутум криминалистика куралын жаңы версияларга өткөрүү үчүн кайсы төмөн деңгээлдеги түзүмдөр керек болорун изилдөө аркылуу аныкталган.

Тандалган түзүмдөр тобунда Runtime, Thread жана Heap баш болуп, thread enumeration, memory mapping жана object recovery үчүн керектүү жардамчы түзүмдөр бар.

RQ1 — ART китепканасынын өлчөмү кандай өзгөргөн?

Binary өлчөмү монотондуу өспөйт. x86-64 үчүн Android 10 версиясындагы 147,36 MB мааниден Android 11 версиясында 200,71 MB га өскөн; булак муну болжол менен %36 өсүү деп түшүндүрөт. Android 13 версиясында болсо бардык архитектураларда айкын кичирейүү байкалат. ARM64 мисалында Android 12 версиясындагы 177,09 MB файл Android 13 версиясында 89,76 MB га түшөт.

Изилдөөчүлөр readelf менен текшерүүдө Android 9–12 DWARF 4 форматын, Android 13 жана 14 болсо DWARF 5 форматын колдонорун аныкташкан. Булак DWARF 5 маалыматты тыгызыраак таңгактоого көмөкчү болушу мүмкүн экенин белгилеп, binary өлчөмүнө compiler flag, debug information көлөмү жана оптимизация тандоолору да таасир эте аларын эскертет. Ошондуктан болжол менен 48% өлчөм кыскаруусун ART функциясынын жоголушу деп гана түшүндүрүү туура эмес.

RQ2 — Debug символдорунун саны кандай өзгөргөн?

ARM64 символдорунун саны Android 9 версиясындагы 15.698 маанисинен Android 14 версиясында 19.115 маанисине өскөн; булак муну болжол менен %22 өсүү деп билдирет. Android 13 версиясында кыска мөөнөттүү төмөндөө болгону менен, Android 14 изилденген мезгилдеги эң жогорку символ санына ээ.

Бул жердеги маанилүү жыйынтык — binary өлчөмү Android 13 жана 14 версияларында олуттуу азайганы менен debug символдорунун саны узак мөөнөттө көбөйгөн. Ошондуктан “файл кичирейди, runtime жөнөкөйлөштү” деген жыйынтык чыгарууга болбойт. Булактын түшүндүрмөсү DWARF 5 сыяктуу натыйжалуураак коддоо бай debug маалыматты кичирээк binary ичинде сактай алат деген багытта.

RQ3 — 34 маанилүү түзүмдө канча өзгөрүү табылган?

1067 өзгөрүүнүн 956 өзгөрүү мүчөлөрдүн түзүм ичиндеги орду өзгөрүшү. Бул болжол менен %89,60 көрсөткүчүнө туура келет. Мүчө кошуулар болжол менен %6,37, мүчө өчүрүүлөр болжол менен %3,66 жана бүтүндөй түзүмдү өчүрүү болжол менен %0,37.

Эң көп өзгөрүү Android 9→10 өтүүсүндө. Андан кийин Android 11→12 өтүүсүндө жалпы өзгөрүү саны 109 санына чейин азайган, бирок Android 12→13 жана 13→14 мезгилдеринде кайрадан айкын түзүмдүк кыймыл байкалган.

Булак баянындагы 355 жана 201 сандары бүтүндөй түзүм өчүрүүлөрүн жалпы санга кошпогондуктан, жогорудагы таблица түздөн-түз булактагы II таблицанын маанилерине ылайык даярдалган.

Эмне Үчүн Бир Гана Эс-Тутум Офсетинин Өзгөрүшү Криминалистикалык Талдоону Бузушу Мүмкүн?

Эс-тутум криминалистика куралдары көп учурда маалымат түзүмүнүн белгилүү мүчөсүнө түзүмдүн башынан туруктуу byte аралык аркылуу жетет; Android жаңыртуусу ошол эле мүчөнү башка офсетке жылдырганда эски профиль туура эмес эс-тутум ордун окушу мүмкүн. Эгер бул ката thread тизмесинин, heap pointerдын же объекттин class маалыматынын баштапкы чекитинде болсо, кийинки pointer dereference операциялары да туура эмес чынжырды ээрчип, жогорку деңгээлдеги криминалистикалык reconstruction иши ийгиликсиз болушу мүмкүн.

RQ4 — Runtime, Thread жана Heap бирдей түрдө эволюцияланган эмес

Булак ARTтын үч борбордук түзүмү бири-биринен башка эволюция үлгүсүн көрсөткөнүн билдирет.

9-беттеги 2-сүрөт бул айырманы өзгөчө көрсөтөт: Thread түзүмү Android 9→10 өтүүсүндө кескин секирик кылса, Runtime өзгөрмөлүүрөөк өсүү сызыгын карманат, Heap болсо чектелген өзгөрүү көрсөтөт. Изилдөөчүлөр Android 10 версиясындагы Thread өсүшүнүн маанилүү себептеринин бири катары 4000 byteтан ашык орун ээлеген жаңы interpreter_cache_ мүчөсүн көрсөтүшөт.

Таасир упайы эмнени көрсөтөт?

Изилдөөчүлөр түзүмдүк өзгөрүүнүн санын гана эмес, күчүн да көрсөтүү үчүн 0 менен 1 ортосунда таасир упайын иштеп чыгышкан. Упай үч нерсени чогуу баалайт: офсет өзгөрүүсүнөн таасирленген мүчөлөрдүн үлүшү, кошулган же өчүрүлгөн мүчөлөрдүн жалпы мүчөлөргө катышы жана түзүм өлчөмүндөгү салыштырмалуу өзгөрүүнүн чоңдугу.

Булак бул өлчөөнүн жабык-форма теңдемесин бербегендиктен, бул жерде жаңы формула чыгарылбайт. 10-беттеги 3-сүрөттүн жылуулук картасында Runtime үчүн Android 9→10 офсет өзгөрүүсүнүн таасири 0,90 деңгээлде. Thread ошол өтүүдө жогорку өзгөрүүнү көрсөтсө, кийинки версияларда көпчүлүк көрсөткүчтөр боюнча төмөн таасир упайларына түшөт. Heap жалпысынан төмөн жана туруктуу таасир деңгээлдеринде калат.

RQ5 — Thread enumeration кандай таасирленет?

Android процессиндеги threadлерди табуу үчүн Runtime түзүмүнөн thread_list_ талаасына жетип, андан ThreadList ичиндеги эки тараптуу байланышкан thread чынжырын ээрчиш керек. Бирок thread_list_ талаасынын офсети Android 9 версиясынан 14 версиясына мындай өзгөргөн:

Бул жерде бир багыттуу, алдын ала божомолдоого боло турган өсүү же азайуу үлгүсү жок. Мурунку версиянын туруктуу маанисин жаңы версияга көчүрүү коопсуз эмес.

Thread идентификаторун чечмелөөдө колдонулган name_ жана tid_ сыяктуу талаалар да каралган версиялардын болжол менен жарымында ордун өзгөрткөнү билдирилген. tls_32bit_sized_values ичиндеги park_state_ талаасы Android 10 версиясында 60 офсетинде пайда болуп, Android 14 версиясында 44 офсетине жылган.

Heap талдоосу кандай таасирленет?

Heap талдоосунун негизги кирүү чекиттеринин бири кайра эле Runtime ичиндеги heap_ pointerы. Изилдөөдө бул талаа Android 9→14 аралыгында 448 → 400 → 392 → 416 → 512 → 512 офсеттеринде жайгашканы көрсөтүлгөн.

Heap ичиндеги region_space_ талаасы да Android 9 версиясындагы 728 офсетинен Android 14 версиясында 840 офсетине жылган. RegionSpace ичинде аймактардын санын түшүнүүдө колдонулган num_regions_ сыяктуу маанилүү талаалар да бир нече жолу кайра жайгаштырылганы айтылат.

Бул өзгөрүүлөр жөн гана “бир даректи жаңырт” маселеси эмес; threadлер Thread Local Allocation Buffer колдонуп heap аймактарына объект бөлүштүрө алгандыктан, thread, heap жана object-recovery маалыматы бири-бири менен байланыштуу.

Объект reconstruction эмне үчүн кыйыныраак болуп калды?

Колдонмо деңгээлиндеги далилдер көп учурда класстардын instanceлары жана бул объекттердеги instance же static fieldдар түрүндө эс-тутумда жайгашат. Ошондуктан Android объектин туура class түзүмүнө байланыштыруу жана fieldдарын чечмелөө колдонуучу мейкиндигиндеги криминалистикалык талдоонун борборунда турат.

Android 9–12 мезгилинде Object жана Class менен байланышкан талааларда офсет өзгөрүүлөрү байкалса, Android 12→13 өтүүсүндө андан да негизги өзгөрүү болгон: изилдөө Object жана Class кошо айрым негизги түзүмдөр libart.so ичинен алынып салынганын билдирет. Бул эски талдоо кодунун жаңы офсет таблицасы менен гана ишин улантуусун кыйындатат.

Android 10 версиясындагы JIT өзгөрүүсү эмне үчүн түзүм өлчөмүнөн да маанилүү?

Булак Android 9→10 мезгилинде profiler-based Just-In-Time compilation колдоосу менен бирге JitCodeCache жана ProfilingInfo сыяктуу түзүмдөр пайда болгонун белгилейт.

Android 9 жана андан мурунку түзүлүштөрдө DexFile instanceлары OATFileлар ичинде жайгашып, OatFileManager аркылуу жеткиликтүү болгон. DroidScraper сыяктуу куралдар ушул байланышты колдонуп DexFile instanceларына жете алган.

Android 10 версиясынан кийин OatFileManager колдонмого тиешелүү OAT файлдарынын мурдагыдай менеджери болбой калган. Булак жаңы версияларда колдонмо DexFile instanceларына жетүү үчүн төмөнкүдөй татаалыраак байланыш чынжырын ээрчүү керек экенин түшүндүрөт:

JitCodeCache → ProfilingInfo → ArtMethod → DexCache → DexFile

Бул мисал изилдөөнүн негизги билдирүүсүн күчтүү көрсөтөт: жаңы Android версиясында бардык офсеттерди туура билүү да эски алгоритм иштейт деп кепилдик бербейт; кээде түзүмдөр арасындагы семантикалык байланыш жана жетүү жолу да өзгөрөт.

Эң кеңири жыйынтык: %73,2 түзүмдүк орун өзгөрүүсү

Талкуу бөлүмүндө изилдөөчүлөр версиялар арасында бар бойдон калган бардык түзүм мүчөлөрүн чогуу баалашкан. Бул мүчөлөрдүн %73,2 бөлүгү Android 9–14 аралыгында кеминде бир жолу башка офсетке жылган.

Runtimeтын %89,4 көрсөткүчү өзгөчө маанилүү; анткени Runtime башка көптөгөн түзүмдөргө жетүүнүн борборунда турат. Мындай борбордук түзүмдөгү кеңири орун алмашуу бир гана plugin же parser функциясынан да кең код чынжырына таасир этиши мүмкүн.

Android Эс-Тутум Криминалистика Куралдарында Офсеттерди Гана Жаңыртуу Жетиштүүбү?

Жок. Изилдөө айрым Android өтүүлөрүндө түзүм мүчөлөрүнүн орду гана эмес, түзүмдөрдүн өзү бар-жогу, китепканалар арасындагы жайгашуусу жана башка түзүмдөргө жетүү жолдору да өзгөрөрүн көрсөтөт. Ошондуктан жаңы версияга ыңгайлашуу кээде туруктуу офсет таблицасын жаңыртуудан кыйла көбүрөөк нерсени; версияны эске алган parsing, альтернативдүү discovery жолдору жана семантикалык байланыштарды кайра кура ала турган талдоо ыкмаларын талап кылат.

Авторлор сунуштаган гибрид ыкма

Изилдөөчүлөр символго негизделген криминалистикадан толук баш тартууга каршы. Символдор түзүмдөрдүн маанисин жана булак код менен из салуу мүмкүнчүлүгүн камсыз кылгандыктан, криминалистикалык текшерүү үчүн баалуу. Маселе — аларды жалгыз колдонууда.

Сунушталган келечектеги курал архитектурасында бир нече мүмкүнчүлүктү бирге колдонуу өзгөчө белгиленет:

• Түзүм аныктамаларын Android версиясына жараша тандаган версияны эске алган parsing.
• Туруктуу layout менен parser логикасын бири-биринен бөлгөн модулдук архитектура.
• Версияга тиешелүү түзүм карталары менен жалпы талдоо кодун бирге колдонуу.
• Runtime жана Thread сыяктуу маанилүү кирүү чекиттери үчүн бир нече discovery жолу.
• Символ иштебей калганда memory scanning же жүрүм-турумдук pattern tracing сыяктуу резервдик ыкмалар.
• Түзүмдөр код ичинде кандай колдонуларын талдаган symbolic execution.
• Келечекте directed symbolic execution менен memory-access-pattern талдоосун бирге колдонуу.

Булак Seance аттуу мурдагы proof-of-concept ишин символдук аткаруунун мүмкүнчүлүгүнө мисал катары берет; бирок global variable шилтемелериндеги айрым өзгөрүүлөрдү аныктай албай калышы сыяктуу көйгөйлөрдү да ачык белгилейт. Демек, symbolic execution да жалгыз өзү кемчиликсиз чечим катары көрсөтүлбөйт.

Изилдөө колдогон жыйынтыктар

• Android 9–14 аралыгында ART түзүмдөрүнүн ички жайгашуулары олуттуу өзгөрөт.
• 34 маанилүү түзүмдө эң кеңири өзгөрүү түрү мүчө офсеттеринин кайра жайгаштырылышы.
• Runtime, Thread жана Heap бирдей эволюция үлгүсүн көрсөтпөйт.
• Thread enumeration, heap analysis жана object reconstruction бул өзгөрүүлөрдөн түздөн-түз таасирленет.
• Static symbol/profile ыкмасын жалгыз улантуу барган сайын көбүрөөк техникалык тейлөөнү талап кылат.
• Түзүмдүк байланыштар өзгөргөндө офсет таблицаларын гана жаңыртуу жетишсиз болушу мүмкүн.
• Текшерүүгө боло турган символдук маалыматты ыңгайлашуучу ыкмалар менен айкалыштырган гибрид дизайн — изилдөөчүлөр сунуштаган багыт.

Изилдөө колдобогон жыйынтыктар

• Бардык коммерциялык Android телефондору каралган AOSP eng build түзүүлөрү менен бирдей эс-тутум layoutуна ээ экени көрсөтүлгөн эмес.
• Samsung же башка OEMдердин өзгөртүлгөн firmwareлери түздөн-түз салыштырылган эмес.
• Android 15 жана андан кийинки версиялар эксперименттин чегине киргизилген эмес.
• Сунушталган гибрид ыкмалардын баары production деңгээлинде иштеген бир жаңы криминалистикалык куралда артык экендиги эксперименталдык түрдө көрсөтүлгөн эмес.
• Symbolic execution бардык түзүм өзгөрүүлөрүн кемчиликсиз кармай турган чечим катары далилденген эмес.
• Изилдөө реалдуу сот ишинде далилдин кабыл алынуусун өлчөгөн укуктук валидация эксперименти эмес.

Методологиялык чечмелөө чектери

Изилдөөнүн күчтүү жагы — бир эле AOSP версияларын төрт архитектурада кайра build кылып салыштыруу жана түзүмдүк маалыматты түздөн-түз DWARF жазууларынан чыгаруу. Бул версиялар арасындагы өзгөрүүнү системалуу өлчөөгө мүмкүндүк берет.

Бирок бардык build түзүүлөрү AOSP eng конфигурациясына негизделет. Булактын өзү Androidдин ар башка build режимдери жана OEM өзгөртүүлөрү түзүмдөрдүн санына, түрүнө жана өлчөмүнө таасир этиши мүмкүн экенин белгилейт. Демек, талаадагы түзмөктөрдө кездешүүчү ар түрдүүлүк бул изилдөө дизайнынан кең болушу мүмкүн.

Мындан тышкары, микро деңгээлдеги түзүм салыштыруусу негизинен x86-64 архитектурасында жүргүзүлгөн. Изилдөөчүлөр бул тандоону бир Android версиясындагы символ саны жана түзүм байланыштары архитектуралар арасында өтө окшош экени менен негиздешет; бирок булак alignment себептүү чыныгы эс-тутум layout айырмачылыктары болушу мүмкүн экенин да моюнга алат.

Android 15 изилдөө башталганда чыга элек болгондуктан талдоо Android 14 версиясында аяктайт. Жыйынтыктар Androidдин кийинки версияларында кайсы түзүмдөр өзгөрөрүн так божомолдоо үчүн колдонулбашы керек.

Булак жана Ыкма Жөнүндө Эскертүү

Түпнуска изилдөө: Exploring Runtime Evolution in Android: A Cross-Version Analysis and Its Implications for Memory Forensics

Авторлор: Babangida Bappah, Lauren G Bristol, Lamine Noureddine, Sideeq Bello, Umar Farooq жана Aisha Ali-Gombe

Мекеме: Louisiana State University, USA

Жарыянын түрү: Рецензияланган конференциялык баяндама.

Конференция: 28th International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2025).

Жарыяланган жыл: 2025.

Беттер: 349–362.

Басмакана: IEEE Computer Society.

DOI: 10.1109/RAID67961.2025.00040

arXiv версиясы: arXiv:2512.18517; arXiv жүктөлгөн дата 20 Декабрь 2025.

Негизги изилдөө түрү: Android Runtime маалымат түзүмдөрүнүн версиялар аралык эмпирикалык жана эсептөөчү өлчөө талдоосу.

Каралган Android версиялары: Android 9, 10, 11, 12, 13 жана 14.

Каралган архитектуралар: ARM32, ARM64, x86-32 жана x86-64.

Build конфигурациясы: AOSP eng build.

Негизги binary: libart.so.

Түзүмдүк маалымат булагы: DWARF debug маалыматы.

Parser: ARTтын C++ түзүмүнө атайын иштелип чыккан, pyelftools колдонгон өзгөчө parser.

Талдоо ыкмалары: Cross-Version Binary Profiling жана Symbol-Based Structural Evolution Analysis.

Деталдуу микро талдоо камтуусу: Эс-тутум криминалистикасы үчүн маанилүү 34 ART маалымат түзүмү.

Маалымат/repository абалы: Булак изилдөө Android 9–14 үчүн чыгарылган runtime structure маалыматтары жана изилдөө frameworkи жалпыга жеткиликтүү изилдөө repositoryсинде сакталарын билдирет.

Каржылоо: Изилдөө Department of Homeland Security (DHS) карамагындагы Criminal Investigations and Network Analysis Center (CINA), Grant No. E206378P тарабынан колдоого алынган.

Кызыкчылыктардын кагылышы: Берилген PDFте өзүнчө кызыкчылыктардын кагылышы тууралуу билдирүү табылган эмес.

Автордук салымдар: Берилген PDFте өзүнчө CRediT/автордук салымдар бөлүмү берилген эмес.

Лицензия: Берилген PDF ичинде ишенимдүү ырастала турган ачык лицензия түрү табылбагандыктан, корголгон текст жана түпнуска сүрөттөрдү кайра колдонууда ачык лицензия бар деп кабыл алынган эмес. Verianla баяны илимий фактылар, ыкмалар жана билдирилген сандык жыйынтыктар аркылуу өз алдынча түзүлгөн.

Булак ичиндеги сандык дал келбестик: II таблица Android 9→10 үчүн 356 жана Android 12→13 үчүн 204 жалпы өзгөрүүнү көрсөтсө, айланасындагы баянда тиешелүүлүгүнө жараша 355 жана 201 берилет. Айырма баяндагы эсептөө бүтүндөй түзүм өчүрүүлөрүн жалпы эсепке кошпогондуктан келип чыккан. Verianla таблицаларында булактагы II таблицанын категориялык маанилери сакталган.

Негизги чечмелөө чеги: Изилдөө AOSP eng build түзүүлөрүн жана Android 9–14 мезгилин карайт. OEM firmware ар түрдүүлүгү, башка build профилдери жана Android 15 версиясынан кийинки түзүмдөр түздөн-түз өлчөнгөн эмес. Сунушталган гибрид криминалистикалык талдоо ыкмасы келечектеги курал өнүктүрүү үчүн илимий сунуш; бул изилдөөдө бардык компоненттерди бириктирген жаңы production куралынын талаадагы ийгилиги сыналган эмес.

Автордук укук жана баяндоо ыкмасы: Булактын түпнуска сүйлөмдөрү, абзац ирети же сүрөт дизайндары кайра түзүлгөн эмес. Verianla тексти булакта билдирилген түзүм өзгөрүүлөрү, binary жана symbol өлчөөлөрү, офсет маанилери, ыкма кадамдары жана чечмелөө чектери чыгарылып, өз алдынча окутуучу архитектура менен түзүлгөн.