Bu çalışma, Android 9'dan Android 14'e kadar Android Runtime'ın yapısal olarak nasıl değiştiğini ve bu değişimlerin kullanıcı alanı bellek adli bilişimi üzerindeki etkisini sistematik biçimde ölçmektedir. Android Runtime (ART), Android uygulamalarının yürütülmesini destekleyen; nesne oluşturma, thread yaşam döngüsü ve bellek yönetimi gibi çalışma zamanı işlevlerini yöneten temel yazılım katmanıdır. Araştırmacılar altı Android sürümünü ARM32, ARM64, x86-32 ve x86-64 olmak üzere dört mimaride AOSP kaynaklarından derlemiş; her derlemedeki libart.so dosyasının DWARF hata ayıklama bilgilerini özel bir ayrıştırıcıyla çıkararak yapı adlarını, yapı boyutlarını, üyeleri ve bellek ofsetlerini sürümler arasında karşılaştırmıştır.

Çalışmanın en önemli sonucu, bir yapının veya alanın aynı isimle sonraki Android sürümünde bulunmasının aynı bellek konumunda bulunacağı anlamına gelmemesidir. Sürümler boyunca varlığını koruyan yapı üyelerinin %73,2'si en az bir kez ofset değiştirmiştir. Runtime yapısındaki üyelerin %89,4'ü, thread yönetimiyle ilişkili üyelerin ise %64,7'si en az bir kez yeniden konumlandırılmıştır. Bu hareketlilik, statik yapı tanımlarına ve sabit ofsetlere dayanan adli analiz araçlarının yeni bir Android sürümünde yanlış veri okuyabilmesine veya tamamen çalışamaz hale gelmesine yol açabilmektedir.

Android 9–14 arasında incelenen 34 kritik adli yapı için Tablo II toplam 1067 yapısal değişiklik göstermektedir: 956 ofset değişikliği, 68 yeni üye, 39 kaldırılmış üye ve dört bütün yapı kaldırılması. Değişikliklerin yaklaşık %89,6'sı yalnızca üyelerin yapı içindeki konumunun değişmesidir. Bu nedenle görünüşte küçük bir kaynak-kod değişikliği bile bellek görüntüsünü yorumlayan bir aracın varsayımlarını bozabilir.

Çalışma, sembol-tabanlı yöntemlerin terk edilmesini önermemektedir. Aksine sembollerin sağladığı doğrulanabilirlik ve izlenebilirliğin korunması; fakat bunun sürüm-farkındalıklı ayrıştırma, otomatik yapı çıkarımı, sembolik yürütme, bellek erişim örüntüsü analizi ve yedek keşif yollarıyla birleştirilmesi gerektiğini savunmaktadır. Bulgular Android 9–14 için AOSP'nin eng derlemelerine dayandığından OEM üretici değişiklikleri, farklı build modları ve Android 15 sonrası sürümler doğrudan test edilmemiştir.

Bellek adli bilişimi neden yalnız disk incelemesinden ibaret değildir?

Bir uygulama çalışırken önemli bilgiler yalnız kalıcı depolamada bulunmaz. Açık uygulama durumları, geçici kullanıcı etkileşimleri, çözümlenmiş nesneler, çalışma zamanı metadata'sı ve henüz diske yazılmamış başka bilgiler RAM içinde bulunabilir. Kullanıcı alanı bellek adli bilişimi, özellikle uygulamaya özgü bu geçici verileri anlamaya çalışır.

Ancak ham bir bellek görüntüsünde belirli bir byte dizisinin ne anlama geldiği kendiliğinden bilinmez. Analiz aracı, bir Runtime, Thread, Heap, Class veya başka C++ yapısının hangi üyelerden oluştuğunu ve her üyenin yapının başlangıcından itibaren kaç byte ötede bulunduğunu bilmek zorundadır. Bu mesafeye bellek ofseti denir.

Örneğin bir araç bir thread listesinin adresinin Runtime yapısında belirli bir ofsette olduğunu varsayıyorsa, Android'in yeni sürümünde başka üyelerin eklenmesi nedeniyle bu alan birkaç düzine byte kaydığında eski araç artık thread listesini değil başka bir alanı okuyabilir. Bellek adli bilişiminde tek bir yanlış adres çözümlemesi, sonraki bütün nesne zincirini etkileyebilir.

Android Runtime (ART) Nedir ve Bellek Adli Bilişimi İçin Neden Kritiktir?

Android Runtime (ART), Android uygulamalarının yürütülmesi sırasında bellek tahsisini, nesne yaşamını, thread yönetimini, garbage collection süreçlerini ve uygulama kodunun çalıştırılmasıyla ilişkili çok sayıda iç yapıyı yöneten çalışma zamanı sistemidir. Kullanıcı alanı bellek adli bilişimi bu yapılardaki pointer, üye ve ilişkilere dayanarak thread'leri, heap bölgelerini ve uygulama nesnelerini yeniden oluşturabildiği için ART'ın sürümler arasındaki yapısal değişimi doğrudan adli araçların güvenilirliğini etkiler.

Dalvik'ten ART'a geçiş neden önemliydi?

Android'in çalışma zamanı mimarisi zaman içinde önemli ölçüde değişmiştir. Dalvik döneminden ART'a geçiş yalnız bir isim değişikliği değildir; uygulama kodunun yürütülme biçimi, bellek tahsisi, garbage collection ve iç veri yapıları da değişmiştir. ART ile birlikte RosAlloc gibi bellek ayırıcıları ve daha sonraki sürümlerde Region Space Allocation gibi yapılar adli analiz açısından önemli hale gelmiştir.

RosAlloc, heap belleğini belirli büyüklükteki nesneler için slotlardan oluşan bölgelere ayırır. Daha büyük nesneler ise Large Object Space gibi farklı alanlara taşınabilir. Android 8 sonrasında Concurrent Copying ve Region Space Allocation'ın temel hale gelmesi, daha eski bellek kurtarma tekniklerinin doğrudan yeni sürümlere taşınmasını zorlaştırmıştır.

Buradaki temel mesele Android'in aynı genel ART çatısını korumasına rağmen iç yapılarının sabit kalmamasıdır. Aynı işlev yıllar boyunca varlığını sürdürebilir fakat ona erişmek için kullanılan yapı, pointer zinciri veya üye konumu değişebilir.

Çalışmanın beş araştırma sorusu

Neden dört mimari incelendi?

Araştırmacılar ARM ve x86 ailelerinin hem 32-bit hem 64-bit sürümlerini incelemiştir: ARM32, ARM64, x86-32 ve x86-64. Bunun nedeni yalnız Android sürümünün değil işlemci mimarisinin de pointer boyutu, alignment ve bellek yerleşimi üzerinde etkili olabilmesidir.

Bununla birlikte sembol sayılarının aynı Android sürümü içindeki dört mimaride son derece yakın olduğu görülmüştür. Örneğin Android 14 için sembol sayısı ARM64'te 19.115, x86-64'te 19.100, ARM32'de 19.107 ve x86-32'de 19.097'dir. Bu nedenle araştırmacılar ayrıntılı mikro-yapısal karşılaştırmada x86-64'ü temsilci mimari olarak kullanmıştır. Bu karar, byte düzeyindeki bütün mimari yerleşimlerin aynı olduğu anlamına gelmez; kaynak özellikle alignment farklılıklarının bellek yerleşimini etkileyebildiğini belirtmektedir.

Sembol-Tabanlı Bellek Adli Bilişimi Nedir?

Sembol-tabanlı veya profil-tabanlı bellek adli bilişimi, derleyicinin ürettiği hata ayıklama bilgilerinden veri yapılarının adlarını, boyutlarını, üyelerini ve üye ofsetlerini çıkararak bellek görüntüsünün anlamlandırılmasına dayanan yaklaşımdır. Bu yöntem yüksek izlenebilirlik ve doğrulama gücü sağlar; ancak yapı tanımları her Android sürümünde değiştiğinde profillerin ve bunları kullanan ayrıştırma kodunun sürekli güncellenmesi gerekir.

DWARF burada ne işe yarıyor?

DWARF, derlenmiş ikili dosyalarda hata ayıklama amacıyla yapı ve değişken bilgilerini taşıyabilen bir debug information biçimidir. Araştırma, libart.so içindeki DWARF bilgisini kullanarak ART'ın C++ yapılarının isimlerini, toplam byte boyutlarını ve üyelerin yapı içindeki konumlarını çıkarır.

ART'ın yoğun biçimde C++ inheritance, template ve karmaşık nesne yönelimli yapı kullanması nedeniyle standart dwarf2json yaklaşımının araştırmacıların ihtiyacını karşılamadığı belirtilmiştir. Bunun üzerine pyelftools tabanlı özel bir parser geliştirilmiştir.

Parser, DWARF içindeki Compilation Unit'leri ve Debugging Information Entry kayıtlarını dolaşır; DW_TAG_class_type, DW_TAG_structure_type ve DW_TAG_member gibi kayıtları kullanarak yapı adını, byte boyutunu ve DW_AT_data_member_location üzerinden üye konumunu çıkarır. Elde edilen bilgiler sürüm ve mimari başına yapılandırılmış JSON dosyalarına dönüştürülür.

Çalışmanın kapsam sınırı

Araştırma Android 9, 10, 11, 12, 13 ve 14'ü kapsamaktadır. Android 15 araştırma başladığında henüz yayımlanmadığı için analize alınmamıştır. Bütün derlemelerde geliştirme ve debug özellikleri sağlayan AOSP eng build varyantı kullanılmıştır.

Kaynak ayrıca Android'in user, debug, eng ve release gibi farklı build yapılandırmalarının; mimari seçeneklerinin ve Samsung gibi OEM üreticilerin özelleştirmelerinin yapı sayısı, veri tipi ve boyutlarında ilave farklılıklar yaratabileceğini açıkça belirtmektedir. Dolayısıyla çalışmanın sonuçları “bütün ticari Android telefonlarda byte düzeyinde aynı yapılar vardır” biçiminde yorumlanamaz.

Çalışmanın Yöntemi ve Bulguları

Çalışma akışı

Kaynak çalışmanın sayfa 5'teki Şekil 1'i de bu mantığı gösterir: AOSP sürümleri önce derlenmekte ve sembolleri çıkarılmakta; ardından makro ve mikro düzey analizleri yapılmakta; sonuçlar thread, heap ve nesne kurtarma üzerindeki etkilerle ilişkilendirilerek önerilere dönüştürülmektedir.

Derleme ortamı

AOSP derlemeleri Linux tabanlı bir sistemde gerçekleştirilmiştir. Kaynak, deney makinesini 13. nesil Intel Core i9-13900KF işlemci, 64 GB RAM ve 4 TB depolama ile tanımlar. Her sürüm için ayrı ve temiz bir build environment kurulmuş; Git, Python, OpenJDK ve Android Repo aracı kullanılmıştır. Kaynak her sürüm derlemesinin yaklaşık 4–5 saat sürdüğünü raporlamaktadır.

Neden 34 yapı seçildi?

Yeni Android sürümlerindeki libart.so dosyalarında 19.000'i aşan DWARF sembolü bulunduğundan bütün yapıların tek tek adli önem açısından analiz edilmesi yerine 34 kritik veri yapısına odaklanılmıştır. Bu yapılar, Android 8, 8.1 ve 9'u destekleyen DroidScraper adlı kullanıcı alanı bellek adli aracının daha yeni sürümlere taşınması için hangi düşük düzey yapıların gerekli olacağı incelenerek belirlenmiştir.

Seçilen yapı grubunda Runtime, Thread ve Heap başta olmak üzere thread enumeration, memory mapping ve object recovery için gereken yardımcı yapılar bulunmaktadır.

RQ1 — ART kütüphanesinin boyutu nasıl değişti?

Binary boyutu monoton biçimde artmamaktadır. x86-64 için Android 10'daki 147,36 MB değerinden Android 11'de 200,71 MB'a çıkılmıştır; kaynak bunu yaklaşık %36'lık büyüme olarak yorumlamaktadır. Android 13'te ise bütün mimarilerde belirgin bir küçülme görülür. ARM64 örneğinde Android 12'nin 177,09 MB'lık dosyası Android 13'te 89,76 MB'a düşmektedir.

Araştırmacılar readelf ile yaptıkları incelemede Android 9–12'nin DWARF 4, Android 13 ve 14'ün DWARF 5 kullandığını tespit etmiştir. Kaynak, DWARF 5'in daha yoğun bilgi paketlemesine katkıda bulunabileceğini belirtirken binary boyutunun compiler flag, debug information miktarı ve optimizasyon seçeneklerinden de etkilenebileceği uyarısını yapmaktadır. Dolayısıyla 48% civarındaki boyut azalmasını tek başına bir ART işlev kaybı olarak okumak doğru değildir.

RQ2 — Debug sembollerinin sayısı nasıl değişti?

ARM64 sembol sayısı Android 9'daki 15.698'den Android 14'te 19.115'e yükselmiştir; kaynak bunu yaklaşık %22 artış olarak raporlamaktadır. Android 13'te kısa süreli düşüş görülmesine rağmen Android 14 incelenen dönemin en yüksek sembol sayısına sahiptir.

Buradaki önemli sonuç, binary boyutunun Android 13 ve 14'te ciddi biçimde azalmasına rağmen debug sembolü sayısının uzun dönemde artmasıdır. Bu nedenle “dosya küçüldü, çalışma zamanı basitleşti” sonucu çıkarılamaz. Kaynağın yorumu, DWARF 5 gibi daha verimli kodlamanın zengin debug bilgisini daha küçük binary içinde taşıyabildiği yönündedir.

RQ3 — 34 kritik yapıda kaç değişiklik bulundu?

1067 değişikliğin 956'sı üyelerin yapı içindeki konumunun değişmesidir. Bu yaklaşık %89,60'a karşılık gelir. Üye eklemeleri yaklaşık %6,37, üye kaldırmaları yaklaşık %3,66 ve bütün yapı kaldırmaları yaklaşık %0,37'dir.

En yoğun değişim Android 9→10 geçişindedir. Daha sonra Android 11→12 geçişinde toplam değişiklik sayısı 109'a kadar düşmüş, ancak Android 12→13 ve 13→14 dönemlerinde yeniden belirgin yapısal hareket görülmüştür.

Kaynak anlatısındaki 355 ve 201 rakamları bütün yapı kaldırmalarını toplama katmadığından yukarıdaki tablo doğrudan kaynak Tablo II değerlerine göre hazırlanmıştır.

Neden Tek Bir Bellek Ofsetinin Değişmesi Adli Analizi Bozabilir?

Bellek adli araçları çoğu zaman bir veri yapısının belirli üyesine yapı başlangıcından sabit bir byte uzaklığıyla erişir; Android güncellemesi aynı üyeyi başka bir ofsete taşıdığında eski profil yanlış bellek konumunu okuyabilir. Bu hata thread listesinin, heap pointer'ının veya bir nesnenin class bilgisinin başlangıç noktasında oluşursa sonraki pointer dereference işlemleri de yanlış zinciri izleyebilir ve yüksek düzey adli reconstruction işlemi başarısız olabilir.

RQ4 — Runtime, Thread ve Heap aynı biçimde evrilmedi

Kaynak, ART'ın üç merkezî yapısının birbirinden farklı evrim örüntüsü gösterdiğini raporlamaktadır.

Sayfa 9'daki Şekil 2, bu farkı özellikle görünür kılar: Thread yapısı Android 9→10 geçişinde ani bir sıçrama yaparken Runtime daha değişken bir büyüme çizgisi izlemekte, Heap ise daha sınırlı değişmektedir. Araştırmacılar Android 10'daki Thread büyümesinin önemli nedenlerinden biri olarak 4000 byte'tan fazla yer kaplayan yeni interpreter_cache_ üyesini göstermektedir.

Etki skoru neyi gösteriyor?

Araştırmacılar yapısal değişimin yalnız sayısını değil yoğunluğunu göstermek için 0 ile 1 arasında bir etki skoru geliştirmiştir. Skor üç unsuru birlikte değerlendirir: ofset değişikliğinden etkilenen üye oranı, eklenen veya kaldırılan üyelerin toplam üyelere oranı ve yapı boyutundaki göreli değişimin büyüklüğü.

Kaynak bu ölçümün kapalı-form bir denklemini vermediğinden burada yeni bir formül türetilmemektedir. Sayfa 10'daki Şekil 3'ün ısı haritasında Runtime için Android 9→10 ofset değişimi etkisi 0,90 düzeyindedir. Thread aynı geçişte yüksek değişim gösterirken sonraki sürümlerde çoğu ölçütte daha düşük etki skorlarına gerilemektedir. Heap genel olarak daha düşük ve istikrarlı etki düzeylerinde kalmaktadır.

RQ5 — Thread enumeration nasıl etkileniyor?

Bir Android sürecindeki thread'leri bulmak için Runtime yapısından thread_list_ alanına erişmek ve buradan ThreadList içindeki çift bağlı thread zincirini izlemek gerekir. Fakat thread_list_ alanının ofseti Android 9'dan 14'e şu biçimde değişmiştir:

Burada tek yönlü, tahmin edilebilir bir artış veya azalış örüntüsü yoktur. Bir önceki sürümün sabit değerini yeni sürüme taşımak güvenli değildir.

Thread kimliğinin çözülmesinde kullanılan name_ ve tid_ gibi alanların da incelenen sürümlerin yaklaşık yarısında konum değiştirdiği raporlanmıştır. tls_32bit_sized_values içindeki park_state_ alanı Android 10'da ofset 60'ta ortaya çıkmış, Android 14'te ofset 44'e taşınmıştır.

Heap analizi nasıl etkileniyor?

Heap analizinin temel giriş noktalarından biri yine Runtime içindeki heap_ pointer'ıdır. Çalışmada bu alanın Android 9→14 boyunca sırasıyla 448 → 400 → 392 → 416 → 512 → 512 ofsetlerinde bulunduğu gösterilmiştir.

Heap içindeki region_space_ alanı da Android 9'daki 728 ofsetinden Android 14'te 840 ofsetine taşınmıştır. RegionSpace içinde bölge sayısının anlaşılmasında kullanılan num_regions_ gibi kritik alanların da birden çok kez yeniden konumlandırıldığı belirtilmektedir.

Bu değişiklikler yalnız “bir adresi güncelle” problemi değildir; thread'lerin Thread Local Allocation Buffer kullanarak heap bölgelerine nesne ayırabilmesi nedeniyle thread, heap ve object-recovery bilgisi birbirine bağlıdır.

Nesne reconstruction neden daha zor hale geldi?

Uygulama düzeyindeki deliller çoğu zaman sınıfların instance'ları ve bu nesnelerdeki instance veya static field'lar biçiminde bellekte yer alır. Bu nedenle bir Android nesnesini doğru class yapısına bağlamak ve field'larını çözmek kullanıcı alanı adli analizinin merkezindedir.

Android 9–12 döneminde Object ve Class ile ilişkili alanlarda ofset değişimleri görülürken Android 12→13 geçişinde daha temel bir değişiklik gerçekleşmiştir: çalışma, Object ve Class dâhil bazı temel yapıların libart.so içinden kaldırıldığını raporlamaktadır. Bu, eski analiz kodunun yalnız yeni bir ofset tablosuyla devam etmesini zorlaştırmaktadır.

Android 10'daki JIT değişimi neden yalnız yapı boyutundan daha önemli?

Kaynak, Android 9→10 döneminde profiler-tabanlı Just-In-Time compilation desteğiyle birlikte JitCodeCache ve ProfilingInfo gibi yapıların ortaya çıktığını belirtmektedir.

Android 9 ve önceki düzenlerde DexFile instance'ları OATFile'lar içinde bulunuyor ve OatFileManager üzerinden erişilebiliyordu. DroidScraper gibi araçlar bu ilişkiyi kullanarak DexFile örneklerine ulaşabiliyordu.

Android 10 sonrasında OatFileManager uygulamaya özgü OAT dosyalarının aynı biçimde yöneticisi olmaktan çıkmıştır. Kaynak, daha yeni sürümlerde uygulama DexFile örneklerine ulaşmak için şu daha karmaşık ilişki zincirinin izlenmesi gerektiğini açıklamaktadır:

JitCodeCache → ProfilingInfo → ArtMethod → DexCache → DexFile

Bu örnek çalışmanın temel mesajını güçlü biçimde gösterir: yeni Android sürümünde bütün ofsetleri doğru bilmek dahi eski algoritmanın çalışmasını garanti etmez; bazen yapılar arasındaki semantik ilişki ve erişim yolu da değişir.

En geniş sonuç: %73,2 yapısal konum değişikliği

Tartışma bölümünde araştırmacılar sürümler arasında varlığını sürdüren bütün yapı üyelerini birlikte değerlendirmiştir. Bu üyelerin %73,2'si Android 9–14 aralığında en az bir kez farklı bir ofsete taşınmıştır.

Runtime'ın %89,4'lük değeri özellikle önemlidir; çünkü Runtime birçok başka yapıya erişimin merkezinde yer alır. Böyle bir merkez yapıdaki geniş çaplı konum değişikliği, tek bir plugin veya parser fonksiyonundan daha geniş bir kod zincirini etkileyebilir.

Android Bellek Adli Araçlarında Yalnız Ofsetleri Güncellemek Yeterli mi?

Hayır. Çalışma, bazı Android geçişlerinde yalnız yapı üyelerinin konumunun değil yapıların varlığının, kütüphaneler arasındaki yerinin ve başka yapılara erişim yollarının da değiştiğini göstermektedir. Bu nedenle yeni sürüme uyarlama bazen sabit ofset tablosunu yenilemekten çok daha fazlasını; sürüm-farkındalıklı parsing, alternatif discovery yolları ve semantik ilişkileri yeniden kurabilecek analiz tekniklerini gerektirir.

Yazarların önerdiği hibrit yaklaşım

Araştırmacılar sembol-tabanlı adli bilişimin tamamen terk edilmesine karşıdır. Semboller yapıların anlamını ve kaynak kodla izlenebilirliğini sağlaması nedeniyle adli doğrulama açısından değerlidir. Sorun, bunların tek başına kullanılmasıdır.

Önerilen gelecek araç mimarisinde birkaç yeteneğin birlikte kullanılması öne çıkmaktadır:

• Yapı tanımlarını Android sürümüne göre seçen sürüm-farkındalıklı parsing.
• Sabit layout ile parser mantığını birbirinden ayıran modüler mimari.
• Sürüm-spesifik yapı haritalarıyla ortak analiz kodunun birlikte kullanılması.
• Runtime ve Thread gibi kritik giriş noktaları için birden fazla keşif yolu.
• Sembol başarısız olduğunda memory scanning veya davranışsal pattern tracing gibi yedek yöntemler.
• Yapıların kod içinde nasıl kullanıldığını analiz eden symbolic execution.
• Gelecekte directed symbolic execution ile memory-access-pattern analizinin birlikte kullanılması.

Kaynak Seance adlı önceki proof-of-concept çalışmasını sembolik yürütmenin potansiyeline örnek olarak verir; ancak global variable referanslarındaki bazı değişiklikleri tespit edememesi gibi sorunları da açıkça belirtir. Dolayısıyla symbolic execution da tek başına kusursuz çözüm olarak sunulmamaktadır.

Çalışmanın desteklediği sonuçlar

• Android 9–14 arasında ART yapılarının iç yerleşimleri önemli ölçüde değişmektedir.
• 34 kritik yapıda en yaygın değişim türü üye ofsetlerinin yeniden konumlandırılmasıdır.
• Runtime, Thread ve Heap aynı evrim örüntüsünü göstermez.
• Thread enumeration, heap analysis ve object reconstruction bu değişikliklerden doğrudan etkilenmektedir.
• Static symbol/profile yaklaşımını tek başına sürdürmek giderek daha fazla bakım gerektirmektedir.
• Yapısal ilişkiler değiştiğinde yalnız ofset tablolarının güncellenmesi yeterli olmayabilir.
• Doğrulanabilir sembolik bilgiyi daha uyarlanabilir yöntemlerle birleştiren hibrit tasarım, araştırmacıların önerdiği yöndür.

Çalışmanın desteklemediği sonuçlar

• Bütün ticari Android telefonların incelenen AOSP eng derlemeleriyle aynı bellek layout'una sahip olduğu gösterilmemiştir.
• Samsung veya başka OEM'lerin özelleştirilmiş firmware'leri doğrudan karşılaştırılmamıştır.
• Android 15 ve daha sonraki sürümler deney kapsamına alınmamıştır.
• Önerilen hibrit yöntemlerin tamamının production düzeyinde çalışan tek bir yeni adli araçta üstünlüğü deneysel olarak gösterilmemiştir.
• Symbolic execution bütün yapı değişimlerini kusursuz yakalayan bir çözüm olarak kanıtlanmamıştır.
• Çalışma gerçek bir mahkeme davasındaki delil kabul edilebilirliğini ölçen hukuki doğrulama deneyi değildir.

Yöntemsel yorum sınırları

Çalışmanın güçlü yanı, aynı AOSP sürümlerinin dört mimaride yeniden derlenerek karşılaştırılması ve yapısal bilginin doğrudan DWARF kayıtlarından çıkarılmasıdır. Bu, sürümler arası değişimi sistematik biçimde ölçmeye olanak verir.

Buna karşılık bütün derlemeler AOSP eng konfigürasyonunu temel alır. Kaynağın kendisi Android'in farklı build modlarının ve OEM özelleştirmelerinin yapıların sayı, tip ve boyutlarını etkileyebileceğini belirtmektedir. Dolayısıyla saha cihazlarında karşılaşılabilecek çeşitlilik bu çalışma tasarımından daha geniş olabilir.

Ayrıca mikro düzey yapı karşılaştırması esas olarak x86-64 üzerinde gerçekleştirilmiştir. Araştırmacılar bu seçimi aynı Android sürümü içindeki sembol sayısı ve yapı ilişkilerinin mimariler arasında çok benzer olmasıyla gerekçelendirmektedir; ancak kaynak alignment kaynaklı gerçek bellek layout farklılıklarının bulunabileceğini de kabul etmektedir.

Android 15 araştırma başladığında yayımlanmadığından analiz Android 14'te sona ermektedir. Bulgular Android'in sonraki sürümlerinin hangi yapıları değiştireceği konusunda kesin tahmin olarak kullanılmamalıdır.

Kaynak ve Yöntem Notu

Özgün çalışma: Exploring Runtime Evolution in Android: A Cross-Version Analysis and Its Implications for Memory Forensics

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

Kurum: Louisiana State University, USA

Yayın türü: Hakemli konferans bildirisi.

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

Yayın yılı: 2025.

Sayfalar: 349–362.

Yayınevi: IEEE Computer Society.

DOI: 10.1109/RAID67961.2025.00040

arXiv sürümü: arXiv:2512.18517; arXiv yükleme tarihi 20 Aralık 2025.

Temel çalışma türü: Android Runtime veri yapılarının sürümler-arası ampirik ve hesaplamalı ölçüm analizi.

İncelenen Android sürümleri: Android 9, 10, 11, 12, 13 ve 14.

İncelenen mimariler: ARM32, ARM64, x86-32 ve x86-64.

Build konfigürasyonu: AOSP eng build.

Ana binary: libart.so.

Yapısal veri kaynağı: DWARF hata ayıklama bilgisi.

Parser: ART'ın C++ yapısına özel olarak geliştirilen, pyelftools kullanan özel ayrıştırıcı.

Analiz yöntemleri: Cross-Version Binary Profiling ve Symbol-Based Structural Evolution Analysis.

Detaylı mikro analiz kapsamı: Bellek adli bilişimi açısından kritik 34 ART veri yapısı.

Veri/repository durumu: Kaynak çalışma, Android 9–14 için çıkarılan runtime structure bilgilerinin ve çalışma framework'ünün kamuya erişilebilir bir araştırma repository'sinde tutulduğunu bildirmektedir.

Finansman: Çalışma, Department of Homeland Security (DHS) bünyesindeki Criminal Investigations and Network Analysis Center (CINA), Grant No. E206378P tarafından desteklenmiştir.

Çıkar çatışması: Sağlanan PDF'de ayrı bir çıkar çatışması beyanı tespit edilmemiştir.

Yazar katkıları: Sağlanan PDF'de ayrı bir CRediT/yazar katkıları bölümü verilmemiştir.

Lisans: Sağlanan PDF içinde güvenilir biçimde doğrulanabilen açık lisans türü bulunmadığından korunan metin ve özgün şekillerin yeniden kullanımında açık lisans varsayılmamıştır. Verianla anlatımı bilimsel olgular, yöntemler ve raporlanan nicel sonuçlar üzerinden bağımsız biçimde kurulmuştur.

Kaynak içi nicel tutarsızlık: Tablo II Android 9→10 için 356 ve Android 12→13 için 204 toplam değişiklik gösterirken çevredeki anlatı sırasıyla 355 ve 201 vermektedir. Fark, anlatıdaki hesaplamanın bütün yapı kaldırmalarını toplam dışında bırakmasından kaynaklanmaktadır. Verianla tablolarında kaynak Tablo II'nin kategori bazlı değerleri korunmuştur.

Temel yorum sınırı: Çalışma AOSP eng build'lerini ve Android 9–14 dönemini inceler. OEM firmware çeşitliliği, diğer build profilleri ve Android 15 sonrası yapılar doğrudan ölçülmemiştir. Önerilen hibrit adli analiz yaklaşımı gelecek araç geliştirmesi için bilimsel öneridir; bu çalışmada tüm bileşenleri bir araya getiren yeni production aracının saha başarısı test edilmemiştir.

Telif ve anlatım yöntemi: Kaynağın özgün cümleleri, paragraf sırası veya şekil tasarımları yeniden üretilmemiştir. Verianla metni; kaynakta raporlanan yapı değişiklikleri, binary ve symbol ölçümleri, ofset değerleri, yöntem adımları ve yorum sınırları çıkarılarak bağımsız öğretici mimariyle oluşturulmuştur.