Aşağıdaki bölümlerde, yaygın yerel kilitlenme türleri, örnek bir kilitlenme dökümünün analizi ve mezar taşları hakkında bir tartışma yer almaktadır. Her kilitlenme türü, belirli kilitlenme türünü ayırt etmenize yardımcı olmak için temel kanıtların vurgulandığı örnek bir debuggerd çıkışı içerir.
İptal et
İptaller, bilinçli oldukları için ilgi çekicidir. İptal etmenin birçok farklı yolu vardır (abort(3) çağrısı yapmak, assert(3) başarısızlığı, Android'e özgü ölümcül günlük kaydı türlerinden birini kullanmak dahil). Ancak bunların tümü abort çağrısını içerir. abort çağrısı, çağıran iş parçacığına SIGABRT ile sinyal gönderir. Bu nedenle, bu durumu tanımak için debuggerd çıkışında libc.so'te "abort"u ve SIGABRT'ı gösteren bir çerçeve aranmalıdır.
Belirli bir "abort message" satırı olabilir. assert(3) veya yüksek düzeydeki ölümcül günlük kaydetme olanaklarının aksine abort(3) bir mesajı kabul etmediğinden, bu ileti dizisinin kendini kasten öldürmeden önce neleri günlüğe kaydettiğini görmek için logcat çıkışına da bakmanız gerekir.
Android'in mevcut sürümleri tgkill(2)
sistem çağrısını satır içi olarak kullandığından, yığınları en kolay okunur. Bu yığınlarda abort(3) çağrısı en üstte yer alır:
pid: 4637, tid: 4637, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 0000121d r2 00000006 r3 00000008
r4 0000121d r5 0000121d r6 ffb44a1c r7 0000010c
r8 00000000 r9 00000000 r10 00000000 r11 00000000
ip ffb44c20 sp ffb44a08 lr eace2b0b pc eace2b16
backtrace:
#00 pc 0001cb16 /system/lib/libc.so (abort+57)
#01 pc 0001cd8f /system/lib/libc.so (__assert2+22)
#02 pc 00001531 /system/bin/crasher (do_action+764)
#03 pc 00002301 /system/bin/crasher (main+68)
#04 pc 0008a809 /system/lib/libc.so (__libc_init+48)
#05 pc 00001097 /system/bin/crasher (_start_main+38)
Android'in eski sürümleri, orijinal iptal çağrısı (burada 4. kare) ile sinyalin gerçek gönderilmesi (burada 0. kare) arasında karmaşık bir yol izliyordu.
Bu durum özellikle 32 bit ARM'de geçerliydi. Bu platform, diğer platformların raise/pthread_kill/tgkill sırasına __libc_android_abort (burada 3. çerçeve) ekledi:
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
crasher
abort aracını kullanarak bu tür bir kilitlenmeyi yeniden oluşturabilirsiniz.
Saf boş işaretçi referans atama
Bu, klasik doğal kilitlenmedir ve sonraki kilitlenme türünün özel bir durumu olmasına rağmen genellikle en az düşünmeyi gerektirdiği için ayrı olarak belirtilmelidir.
Aşağıdaki örnekte, kilitlenme işlevi libc.so içinde olsa da dize işlevleri yalnızca kendilerine verilen işaretçiler üzerinde çalıştığından strlen(3) işlevinin boş bir işaretçiyle çağrıldığı sonucuna varabilirsiniz. Bu kilitlenme, doğrudan çağıran kodun yazarına gönderilmelidir. Bu durumda, 01 numaralı kare kötü arayandır.
pid: 25326, tid: 25326, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
r0 00000000 r1 00000000 r2 00004c00 r3 00000000
r4 ab088071 r5 fff92b34 r6 00000002 r7 fff92b40
r8 00000000 r9 00000000 sl 00000000 fp fff92b2c
ip ab08cfc4 sp fff92a08 lr ab087a93 pc efb78988 cpsr 600d0030
backtrace:
#00 pc 00019988 /system/lib/libc.so (strlen+71)
#01 pc 00001a8f /system/xbin/crasher (strlen_null+22)
#02 pc 000017cd /system/xbin/crasher (do_action+948)
#03 pc 000020d5 /system/xbin/crasher (main+100)
#04 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#05 pc 000010e4 /system/xbin/crasher (_start+96)
crasher
strlen-NULL aracını kullanarak bu tür bir kilitlenmeyi yeniden oluşturabilirsiniz.
Düşük adresli boş işaretçi referans atama
Çoğu durumda hata adresi 0 değil, başka bir düşük sayı olur. Özellikle iki veya üç haneli adresler çok yaygındır. Bununla birlikte, altı haneli bir adres neredeyse hiç boş işaretçi referansı değildir. Bunun için 1 MiB ofset gerekir. Bu durum genellikle, boş bir işaretçiyi geçerli bir yapı gibi referans veren bir kodunuz olduğunda ortaya çıkar. Genellikle kod, önce fopen(3) veya opendir(3) çağrısının başarılı olup olmadığını kontrol etmediğinden, yaygın işlevler fprintf(3) (veya FILE* alan başka bir işlev) ve readdir(3)'dur.
readdir örneğini aşağıda görebilirsiniz:
pid: 25405, tid: 25405, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
r0 0000000c r1 00000000 r2 00000000 r3 3d5f0000
r4 00000000 r5 0000000c r6 00000002 r7 ff8618f0
r8 00000000 r9 00000000 sl 00000000 fp ff8618dc
ip edaa6834 sp ff8617a8 lr eda34a1f pc eda618f6 cpsr 600d0030
backtrace:
#00 pc 000478f6 /system/lib/libc.so (pthread_mutex_lock+1)
#01 pc 0001aa1b /system/lib/libc.so (readdir+10)
#02 pc 00001b35 /system/xbin/crasher (readdir_null+20)
#03 pc 00001815 /system/xbin/crasher (do_action+976)
#04 pc 000021e5 /system/xbin/crasher (main+100)
#05 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#06 pc 00001110 /system/xbin/crasher (_start+96)
Burada kilitlenmenin doğrudan nedeni, pthread_mutex_lock(3) sınıfının 0xc adresine (0. çerçeve) erişmeye çalışmasıdır. Ancak pthread_mutex_lock'ün yaptığı ilk şey, kendisine verilen pthread_mutex_t* öğesinin state öğesine referans vermeyi kaldırmaktır. Kaynağa bakarsanız öğenin yapıda 0 ofsetinde olduğunu görebilirsiniz. Bu, pthread_mutex_lock için geçersiz işaretçi 0xc'nin atandığını gösterir. 1. karede, bu işaretçiyi readdir'ün verdiğini görebilirsiniz. readdir, kendisine verilen DIR* alanından mutex_ alanını çıkarır. Bu yapıya baktığınızda mutex_'ün struct DIR içinde sizeof(int) + sizeof(size_t) + sizeof(dirent*) ofsetinde olduğunu görebilirsiniz. Bu ofset, 32 bitlik bir cihazda 4 + 4 + 4 = 12 = 0xc değerine sahiptir. Bu nedenle hatayı buldunuz: readdir, çağıran tarafından boş bir işaretçi iletildi. Bu noktada, yığını yığın aracına yapıştırarak bunun logcat'te nerenin yakınında gerçekleştiğini öğrenebilirsiniz.
struct DIR {
int fd_;
size_t available_bytes_;
dirent* next_;
pthread_mutex_t mutex_;
dirent buff_[15];
long current_pos_;
};
Çoğu durumda bu analizi atlayabilirsiniz. Yeterince düşük bir hata adresi genellikle yığıntaki tüm libc.so çerçevelerini atlayabilir ve doğrudan çağıran kodu suçlayabileceğiniz anlamına gelir. Ancak her zaman böyle değildir. Bu nedenle, ikna edici bir durum sunmanız gerekir.
crasher
fprintf-NULL veya crasher readdir-NULL kullanarak bu tür kilitlenme örneklerini yeniden oluşturabilirsiniz.
FORTIFY hatası
FORTIFY hatası, C kitaplığı güvenlik açığı oluşturabilecek bir sorun tespit ettiğinde ortaya çıkan özel bir kesinti durumudur. Birçok C kitaplığı işlevi güçlendirilmiştir. Bu işlevler, bir arabelleğin gerçekte ne kadar büyük olduğunu belirten ek bir bağımsız değişken alır ve çalıştırma zamanında, gerçekleştirmeye çalıştığınız işlemin gerçekten sığıp sığmadığını kontrol eder. Aşağıda, kodun read(fd, buf, 32) değerini aslında yalnızca 10 bayt uzunluğundaki bir arabelleğe yerleştirmeye çalıştığı bir örnek verilmiştir...
pid: 25579, tid: 25579, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'FORTIFY: read: prevented 32-byte write into 10-byte buffer'
r0 00000000 r1 000063eb r2 00000006 r3 00000008
r4 ff96f350 r5 000063eb r6 000063eb r7 0000010c
r8 00000000 r9 00000000 sl 00000000 fp ff96f49c
ip 00000000 sp ff96f340 lr ee83ece3 pc ee86ef0c cpsr 000d0010
backtrace:
#00 pc 00049f0c /system/lib/libc.so (tgkill+12)
#01 pc 00019cdf /system/lib/libc.so (abort+50)
#02 pc 0001e197 /system/lib/libc.so (__fortify_fatal+30)
#03 pc 0001baf9 /system/lib/libc.so (__read_chk+48)
#04 pc 0000165b /system/xbin/crasher (do_action+534)
#05 pc 000021e5 /system/xbin/crasher (main+100)
#06 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#07 pc 00001110 /system/xbin/crasher (_start+96)
crasher
fortify aracını kullanarak bu tür bir kilitlenmeyi yeniden oluşturabilirsiniz.
-fstack-protector tarafından algılanan yığın bozulması
Derleyicinin -fstack-protector seçeneği, tampon taşmalarına karşı koruma sağlamak için yığın üzerinde tampon içeren işlevlere kontroller ekler. Bu seçenek, platform kodu için varsayılan olarak etkindir ancak uygulamalar için etkin değildir. Bu seçenek etkinleştirildiğinde derleyici, yığıntaki son yerel değişkenin hemen arkasına rastgele bir değer yazmak için işlev prologuna ve bu değeri tekrar okuyup değişmediğinden emin olmak için işlev epiloguna talimatlar ekler. Bu değer değiştiyse bir arabellek taşması nedeniyle üzerine yazılmıştır. Bu nedenle epilog, bir mesajı günlüğe kaydetmek ve işlemi iptal etmek için __stack_chk_fail işlevini çağırır.
pid: 26717, tid: 26717, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'stack corruption detected'
r0 00000000 r1 0000685d r2 00000006 r3 00000008
r4 ffd516d8 r5 0000685d r6 0000685d r7 0000010c
r8 00000000 r9 00000000 sl 00000000 fp ffd518bc
ip 00000000 sp ffd516c8 lr ee63ece3 pc ee66ef0c cpsr 000e0010
backtrace:
#00 pc 00049f0c /system/lib/libc.so (tgkill+12)
#01 pc 00019cdf /system/lib/libc.so (abort+50)
#02 pc 0001e07d /system/lib/libc.so (__libc_fatal+24)
#03 pc 0004863f /system/lib/libc.so (__stack_chk_fail+6)
#04 pc 000013ed /system/xbin/crasher (smash_stack+76)
#05 pc 00001591 /system/xbin/crasher (do_action+280)
#06 pc 00002219 /system/xbin/crasher (main+100)
#07 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#08 pc 00001144 /system/xbin/crasher (_start+96)
Bu durumu, geri izlemede __stack_chk_fail bulunmasına ve belirli bir iptal mesajına sahip olmasına göre diğer iptal türlerinden ayırt edebilirsiniz.
crasher
smash-stack aracını kullanarak bu tür bir kilitlenmeyi yeniden oluşturabilirsiniz.
İzin verilmeyen bir sistem çağrısından Seccomp SIGSYS
seccomp sistemi (özellikle seccomp-bpf), sistem çağrılarına erişimi kısıtlar. Platform geliştiricileri için seccomp hakkında daha fazla bilgi edinmek isterseniz Android O'daki seccomp filtresi başlıklı blog yayınını inceleyin. Kısıtlanmış bir sistem çağrısı yapan bir iş parçacığı, SYS_SECCOMP koduna sahip bir SIGSYS sinyali alır. Sistem çağrı numarası, mimari ile birlikte neden satırında gösterilir. Sistem çağrı numaralarının mimariler arasında farklılık gösterdiğini unutmayın. Örneğin, readlinkat(2) sistem çağrısı x86'da 305, x86-64'te ise 267 numaralıdır.
Çağrı numarası hem arm hem de arm64'te yine farklıdır. Sistem çağrısı sayıları mimariler arasında değişiklik gösterdiğinden, hangi sistem çağrısına izin verilmediğini öğrenmek için genellikle üstbilgilerde sistem çağrısı numarasını aramak yerine yığın izlemeyi kullanmak daha kolaydır.
pid: 11046, tid: 11046, name: crasher >>> crasher <<<
signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
Cause: seccomp prevented call to disallowed arm system call 99999
r0 cfda0444 r1 00000014 r2 40000000 r3 00000000
r4 00000000 r5 00000000 r6 00000000 r7 0001869f
r8 00000000 r9 00000000 sl 00000000 fp fffefa58
ip fffef898 sp fffef888 lr 00401997 pc f74f3658 cpsr 600f0010
backtrace:
#00 pc 00019658 /system/lib/libc.so (syscall+32)
#01 pc 00001993 /system/bin/crasher (do_action+1474)
#02 pc 00002699 /system/bin/crasher (main+68)
#03 pc 0007c60d /system/lib/libc.so (__libc_init+48)
#04 pc 000011b0 /system/bin/crasher (_start_main+72)
İzin verilmeyen sistem çağrılarını, sinyal satırında SYS_SECCOMP ve neden satırında açıklama bulunmasıyla diğer kilitlenmelerden ayırt edebilirsiniz.
crasher
seccomp aracını kullanarak bu tür bir kilitlenmeyi yeniden oluşturabilirsiniz.
Yalnızca yürütme bellek ihlali (yalnızca Android 10)
Yalnızca Android 10'daki arm64 için, ikili dosyaların ve kitaplıkların yürütülebilir segmentleri, kod yeniden kullanma saldırılarına karşı bir güçlendirme tekniği olarak belleğe yalnızca yürütülebilir (okunamaz) olarak eşlendi. Bu azaltma, diğer azaltmalarla kötü bir şekilde etkileşime girdiği için daha sonra kaldırıldı.
Kodun okunamaz hale getirilmesi, SEGV_ACCERR koduyla SIGSEGV oluşturmak için salt yürütme olarak işaretlenmiş bellek segmentlerinin kasıtlı ve kasıtsız olarak okunmasına neden olur. Bu durum, bir hata, güvenlik açığı, kodla karıştırılmış veriler (ör. değişmez veri havuzu) veya kasıtlı bellek iç gözlemi sonucunda ortaya çıkabilir.
Derleyici, kod ve verilerin birbirine karışmadığını varsayar ancak elle yazılmış derleme işleminden kaynaklanan sorunlar ortaya çıkabilir. Çoğu durumda, sabitleri bir .data
bölümüne taşıyarak bu sorunları düzeltebilirsiniz.
Çalıştırılabilir kod bölümlerinde kod iç gözlemi kesinlikle gerekliyse kod okunabilir olarak işaretlemek için önce mprotect(2), ardından işlem tamamlandıktan sonra okunamaz olarak işaretlemek için tekrar çağrılmalıdır.
pid: 2938, tid: 2940, name: crasher64 >>> crasher64 <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x5f2ced24a8
Cause: execute-only (no-read) memory access error; likely due to data in .text.
x0 0000000000000000 x1 0000005f2cecf21f x2 0000000000000078 x3 0000000000000053
x4 0000000000000074 x5 8000000000000000 x6 ff71646772607162 x7 00000020dcf0d16c
x8 0000005f2ced24a8 x9 000000781251c55e x10 0000000000000000 x11 0000000000000000
x12 0000000000000014 x13 ffffffffffffffff x14 0000000000000002 x15 ffffffffffffffff
x16 0000005f2ced52f0 x17 00000078125c0ed8 x18 0000007810e8e000 x19 00000078119fbd50
x20 00000078125d6020 x21 00000078119fbd50 x22 00000b7a00000b7a x23 00000078119fbdd8
x24 00000078119fbd50 x25 00000078119fbd50 x26 00000078119fc018 x27 00000078128ea020
x28 00000078119fc020 x29 00000078119fbcb0
sp 00000078119fba40 lr 0000005f2ced1b94 pc 0000005f2ced1ba4
backtrace:
#00 pc 0000000000003ba4 /system/bin/crasher64 (do_action+2348)
#01 pc 0000000000003234 /system/bin/crasher64 (thread_callback+44)
#02 pc 00000000000e2044 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
#03 pc 0000000000083de0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
Yalnızca çalıştırılabilir bellek ihlallerini, neden satırına göre diğer kilitlenmelerden ayırt edebilirsiniz.
crasher xom aracını kullanarak bu tür bir kilitlenmeyi yeniden oluşturabilirsiniz.
fdsan tarafından algılanan hata
Android'in fdsan dosya tanımlayıcısı temizleyicisi, dosya tanımlayıcılar ile ilgili sık yapılan hataları (ör. kapatıldıktan sonra kullanma ve iki kez kapatma) yakalamanıza yardımcı olur. Bu tür hatalarda hata ayıklama (ve önleme) hakkında daha fazla bilgi için fdsan dokümanlarına bakın.
pid: 32315, tid: 32315, name: crasher64 >>> crasher64 <<< signal 35 (), code -1 (SI_QUEUE), fault addr -------- Abort message: 'attempted to close file descriptor 3, expected to be unowned, actually owned by FILE* 0x7d8e413018' x0 0000000000000000 x1 0000000000007e3b x2 0000000000000023 x3 0000007fe7300bb0 x4 3033313465386437 x5 3033313465386437 x6 3033313465386437 x7 3831303331346538 x8 00000000000000f0 x9 0000000000000000 x10 0000000000000059 x11 0000000000000034 x12 0000007d8ebc3a49 x13 0000007fe730077a x14 0000007fe730077a x15 0000000000000000 x16 0000007d8ec9a7b8 x17 0000007d8ec779f0 x18 0000007d8f29c000 x19 0000000000007e3b x20 0000000000007e3b x21 0000007d8f023020 x22 0000007d8f3b58dc x23 0000000000000001 x24 0000007fe73009a0 x25 0000007fe73008e0 x26 0000007fe7300ca0 x27 0000000000000000 x28 0000000000000000 x29 0000007fe7300c90 sp 0000007fe7300860 lr 0000007d8ec2f22c pc 0000007d8ec2f250 backtrace: #00 pc 0000000000088250 /bionic/lib64/libc.so (fdsan_error(char const*, ...)+384) #01 pc 0000000000088060 /bionic/lib64/libc.so (android_fdsan_close_with_tag+632) #02 pc 00000000000887e8 /bionic/lib64/libc.so (close+16) #03 pc 000000000000379c /system/bin/crasher64 (do_action+1316) #04 pc 00000000000049c8 /system/bin/crasher64 (main+96) #05 pc 000000000008021c /bionic/lib64/libc.so (_start_main)
Bu durumu, geri izlemede fdsan_error bulunmasına ve belirli bir iptal mesajına sahip olmasına göre diğer iptal türlerinden ayırt edebilirsiniz.
crasher fdsan_file veya crasher fdsan_dir kullanarak bu tür bir kilitlenmeyi yeniden oluşturabilirsiniz.
Kilitlenme dökümlerini inceleme
Şu anda araştırdığınız belirli bir kilitlenme yoksa platform kaynağında, debuggerd'ü test etmek için kilitlenme aracı adlı bir araç bulunur. system/core/debuggerd/'te mm yaparsanız yolunuzda hem crasher hem de crasher64 alırsınız (ikincisi 64 bit kilitlenmelerini test etmenize olanak tanır). Kilitleyici, sağladığınız komut satırı bağımsız değişkenlerine bağlı olarak birçok ilginç şekilde kilitlenebilir.
Şu anda desteklenen seçimi görmek için crasher --help simgesini kullanın.
Kilitlenme dökümünde bulunan farklı parçaları tanıtmak için aşağıdaki örnek kilitlenme dökümünü inceleyelim:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Revision: '0'
ABI: 'arm'
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
Tombstone written to: /data/tombstones/tombstone_06
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Yerel kilitlenmeler için bir günlükte arama yapıyorsanız boşluk içeren yıldız satırı faydalıdır. "*** ***" dizesi, yerel kilitlenmenin başlangıcından başka durumlarda günlüklerde nadiren görünür.
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Parmak izi, kilitlenmenin tam olarak hangi sürümde gerçekleştiğini belirlemenize olanak tanır.
Bu, ro.build.fingerprint sistem mülküyle tamamen aynıdır.
Revision: '0'
Düzeltme, yazılım yerine donanımı ifade eder. Bu seçenek genellikle kullanılmaz ancak kötü donanımdan kaynaklandığı bilinen hataları otomatik olarak yok saymanıza yardımcı olmak için yararlı olabilir. Bu, ro.revision sistem mülküyle tamamen aynıdır.
ABI: 'arm'
ABI, arm, arm64, x86 veya x86-64'ten biridir. Bu, çoğunlukla yukarıda bahsedilen stack komut dosyası için kullanışlıdır. Böylece, hangi araç zincirinin kullanılacağını bilir.
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
Bu satır, işlemde kilitlenen mesaj dizisini tanımlar. Bu durumda, işlemin ana iş parçacığı olduğu için işlem kimliği ve iş parçacığı kimliği eşleşiyor. İlk ad, iş parçacığı adıdır. >>> ve <<< ile çevrili ad ise işlem adıdır. Bir uygulamanın işlem adı genellikle tam nitelikli paket adıdır (ör. com.facebook.katana). Bu ad, hata bildirme veya uygulamayı Google Play'de bulmaya çalışırken faydalıdır. pid ve tid, kilitlenmeden önceki ilgili günlük satırlarını bulmak için de yararlı olabilir.
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Bu satırda, hangi sinyalin (SIGABRT) alındığı ve nasıl alındığı (SI_TKILL) hakkında daha fazla bilgi verilir. debuggerd tarafından bildirilen sinyaller: SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV ve SIGTRAP. Sinyale özgü kodlar, sinyale göre değişir.
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
Tüm kilitlenmelerde iptal mesajı satırı bulunmaz ancak iptallerde bulunur. Bu bilgi, bu pid/tid için son satırdaki kritik logcat çıkışından otomatik olarak toplanır ve kasıtlı bir iptal durumunda, programın neden kendini sonlandırdığını açıklama olasılığı yüksektir.
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8 r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
Kayıt dökümü, sinyal alındığı sırada CPU kayıtlarının içeriğini gösterir. (Bu bölüm, ABI'lere göre büyük ölçüde değişiklik gösterir.) Bu bilgilerin ne kadar faydalı olacağı, kilitlenmenin tam olarak nasıl gerçekleştiğine bağlıdır.
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
Geri izleme, kilitlenme sırasında kodun neresinde olduğumuzu gösterir. İlk sütun, kare numarasıdır (en derin karenin 0 olduğu gdb stiliyle eşleşir). PC değerleri, mutlak adresler yerine paylaşılan kitaplığın konumuna görelidir. Sonraki sütunda, eşlenen bölgenin adı (genellikle paylaşılan bir kitaplık veya yürütülebilir dosyadır ancak JIT derlenmiş kod için olmayabilir) yer alır. Son olarak, simgeler kullanılabiliyorsa PC değerinin karşılık geldiği simge, bu simgenin bayt cinsinden ofset değeriyle birlikte gösterilir. İlgili derleyici talimatlarını bulmak için bu komutu objdump(1) ile birlikte kullanabilirsiniz.
Tombstone'ları okuma
Tombstone written to: /data/tombstones/tombstone_06
Bu, debuggerd'ün nerede ek bilgi yazdığını gösterir.
debuggerd, 00 ile 09 arasındaki sayılar arasında geçiş yaparak ve gerektiğinde mevcut yer işaretlerinin üzerine yazarak en fazla 10 yer işareti tutar.
Mezar taşı, kilitlenme dökümüyle aynı bilgileri ve birkaç ek bilgi içerir. Örneğin, tüm mesaj dizilerinin (yalnızca kilitlenen mesaj dizisi değil) geri izlemelerini, kayan nokta kaydedicilerini, ham yığın dökümlerini ve kaydedicilerdeki adreslerin etrafındaki bellek dökümlerini içerir. En yararlı özelliği ise tam bir hafıza haritası (/proc/pid/maps'e benzer) içermesidir. 32 bit ARM işlem kilitlenmesinden alınan ve açıklamalı bir örneği aşağıda bulabilirsiniz:
memory map: (fault address prefixed with --->) --->ab15f000-ab162fff r-x 0 4000 /system/xbin/crasher (BuildId: b9527db01b5cf8f5402f899f64b9b121)
Burada dikkat edilmesi gereken iki nokta vardır. Birincisi, bu satırın önüne "--->" eklenmiş olmasıdır. Haritalar, kilitlenmeniz yalnızca boş işaretçi referans atamadığında en yararlı olur. Hata adresi küçükse muhtemelen boş işaretçi referans almayı gösteren bir varyanttır. Aksi takdirde, hatanın bulunduğu adresin çevresindeki haritalara bakmak genellikle ne olduğuyla ilgili bir ipucu verebilir. Haritalara bakarak tespit edilebilecek bazı olası sorunlar şunlardır:
- Bir bellek bloğunun sonunu aşan okuma/yazma işlemleri.
- Bir bellek bloğunun başlangıcından önce okuma/yazma işlemleri.
- Kod olmayan bir öğeyi çalıştırma girişimleri.
- Bir yığının sonuna kadar koşma.
- Kod yazmaya çalışır (yukarıdaki örnekte olduğu gibi).
İkinci olarak, Android 6.0 ve sonraki sürümlerde çalıştırılabilir dosyaların ve paylaşılan kitaplık dosyalarının BuildId'yi (varsa) gösterdiğini belirtmek isteriz. Böylece, kodunuzun tam olarak hangi sürümünün kilitlendiğini görebilirsiniz. Platform ikili dosyaları, Android 6.0'dan beri varsayılan olarak bir BuildId içerir. NDK r12 ve sonraki sürümler, -Wl,--build-id değerini de bağlayıcıya otomatik olarak iletir.
ab163000-ab163fff r-- 3000 1000 /system/xbin/crasher ab164000-ab164fff rw- 0 1000 f6c80000-f6d7ffff rw- 0 100000 [anon:libc_malloc]
Android'de yığın tek bir bölge olmayabilir. Yığın bölgeleri [anon:libc_malloc] olarak etiketlenir.
f6d82000-f6da1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6da2000-f6dc1fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6dc2000-f6de1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6de2000-f6de5fff r-x 0 4000 /system/lib/libnetd_client.so (BuildId: 08020aa06ed48cf9f6971861abf06c9d) f6de6000-f6de6fff r-- 3000 1000 /system/lib/libnetd_client.so f6de7000-f6de7fff rw- 4000 1000 /system/lib/libnetd_client.so f6dec000-f6e74fff r-x 0 89000 /system/lib/libc++.so (BuildId: 8f1f2be4b37d7067d366543fafececa2) (load base 0x2000) f6e75000-f6e75fff --- 0 1000 f6e76000-f6e79fff r-- 89000 4000 /system/lib/libc++.so f6e7a000-f6e7afff rw- 8d000 1000 /system/lib/libc++.so f6e7b000-f6e7bfff rw- 0 1000 [anon:.bss] f6e7c000-f6efdfff r-x 0 82000 /system/lib/libc.so (BuildId: d189b369d1aafe11feb7014d411bb9c3) f6efe000-f6f01fff r-- 81000 4000 /system/lib/libc.so f6f02000-f6f03fff rw- 85000 2000 /system/lib/libc.so f6f04000-f6f04fff rw- 0 1000 [anon:.bss] f6f05000-f6f05fff r-- 0 1000 [anon:.bss] f6f06000-f6f0bfff rw- 0 6000 [anon:.bss] f6f0c000-f6f21fff r-x 0 16000 /system/lib/libcutils.so (BuildId: d6d68a419dadd645ca852cd339f89741) f6f22000-f6f22fff r-- 15000 1000 /system/lib/libcutils.so f6f23000-f6f23fff rw- 16000 1000 /system/lib/libcutils.so f6f24000-f6f31fff r-x 0 e000 /system/lib/liblog.so (BuildId: e4d30918d1b1028a1ba23d2ab72536fc) f6f32000-f6f32fff r-- d000 1000 /system/lib/liblog.so f6f33000-f6f33fff rw- e000 1000 /system/lib/liblog.so
Paylaşılan kitaplıklarda genellikle üç bitişik giriş bulunur. Bunlardan biri okunabilir ve çalıştırılabilir (kod), biri salt okunur (salt okunur veri) ve biri salt yazılabilir (değiştirilebilir veri). İlk sütunda eşlemenin adres aralıkları, ikinci sütunda izinler (normal Unix ls(1) stilinde), üçüncü sütunda dosyaya göre ofset (onaltılık sistemde), dördüncü sütunda bölgenin boyutu (onaltılık sistemde) ve beşinci sütunda dosya (veya başka bir bölge adı) gösterilir.
f6f34000-f6f53fff r-x 0 20000 /system/lib/libm.so (BuildId: 76ba45dcd9247e60227200976a02c69b) f6f54000-f6f54fff --- 0 1000 f6f55000-f6f55fff r-- 20000 1000 /system/lib/libm.so f6f56000-f6f56fff rw- 21000 1000 /system/lib/libm.so f6f58000-f6f58fff rw- 0 1000 f6f59000-f6f78fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6f79000-f6f98fff r-- 0 20000 /dev/__properties__/properties_serial f6f99000-f6f99fff rw- 0 1000 [anon:linker_alloc_vector] f6f9a000-f6f9afff r-- 0 1000 [anon:atexit handlers] f6f9b000-f6fbafff r-- 0 20000 /dev/__properties__/properties_serial f6fbb000-f6fbbfff rw- 0 1000 [anon:linker_alloc_vector] f6fbc000-f6fbcfff rw- 0 1000 [anon:linker_alloc_small_objects] f6fbd000-f6fbdfff rw- 0 1000 [anon:linker_alloc_vector] f6fbe000-f6fbffff rw- 0 2000 [anon:linker_alloc] f6fc0000-f6fc0fff r-- 0 1000 [anon:linker_alloc] f6fc1000-f6fc1fff rw- 0 1000 [anon:linker_alloc_lob] f6fc2000-f6fc2fff r-- 0 1000 [anon:linker_alloc] f6fc3000-f6fc3fff rw- 0 1000 [anon:linker_alloc_vector] f6fc4000-f6fc4fff rw- 0 1000 [anon:linker_alloc_small_objects] f6fc5000-f6fc5fff rw- 0 1000 [anon:linker_alloc_vector] f6fc6000-f6fc6fff rw- 0 1000 [anon:linker_alloc_small_objects] f6fc7000-f6fc7fff rw- 0 1000 [anon:arc4random _rsx structure] f6fc8000-f6fc8fff rw- 0 1000 [anon:arc4random _rs structure] f6fc9000-f6fc9fff r-- 0 1000 [anon:atexit handlers] f6fca000-f6fcafff --- 0 1000 [anon:thread signal stack guard page]
Android 5.0'den itibaren C kitaplığı, anonim olarak eşlenen bölgelerinin çoğunu adlandırır. Böylece, daha az gizemli bölge olur.
f6fcb000-f6fccfff rw- 0 2000 [stack:5081]
[stack:tid] adlı bölgeler, belirli iş parçacıklarının yığınlarıdır.
f6fcd000-f702afff r-x 0 5e000 /system/bin/linker (BuildId: 84f1316198deee0591c8ac7f158f28b7) f702b000-f702cfff r-- 5d000 2000 /system/bin/linker f702d000-f702dfff rw- 5f000 1000 /system/bin/linker f702e000-f702ffff rw- 0 2000 f7030000-f7030fff r-- 0 1000 f7031000-f7032fff rw- 0 2000 ffcd7000-ffcf7fff rw- 0 21000 ffff0000-ffff0fff r-x 0 1000 [vectors]
[vector] veya [vdso]'ü görüp görmeyeceğiniz mimariye bağlıdır. ARM [vector]'ü, diğer tüm mimariler ise [vdso]'i kullanır.