ghidra disassembler sorunu

[Mikro Step]

Mesela şu string

37431 eklentisine bak

İlgili kod spesifik olarak string'in ortalarından bir yerden alıyor.

37432 eklentisine bak

Bütün string'lerde bu durum yok. İstatistiğini bilmiyorum birçok doğru yerden adresi alınan string de görüyorum yanlış alınan da görüyorum. Her zaman hata 4 ün katı da değil. Bazan 2 kayma da olabiliyor.

Hangi kisim icin hata oldugunu dusunuyorsun?

405b54d8 adresindeki uint 32 bit veri nedir?

 

[taydin]

405b54d8 adresi, ilgili LDR komutuna yakın olan bir adres, relatif adresleme ile içeriği yükleniyor. İçeriği de string'in başlangıç adresi olması lazım iken string'in ortası

İçeriği de bir adres

Ama string baştan itibaren "Retry block recover ..." diye başlayacağına "failure ..." diye başlıyor.

 

[Mikro Step]

405b54d8 adresinde 4079d704 adresi sakli. Verdigin adresdekileri ASCI degil de hex yorumla.

O halde senin stringin 4079d704 adresinde.

 

[taydin]

405b54d8 adresinde 4079D704h var. Ekran çıktısını koydum yukarıda.

 

[taydin]

@Mikro Step konu ile ilgili senle ortak bir noktaya gelemedik bir türlü. ARM ın adresleme modlarını biliyorum, burada bir sorun yok. Sorun, o adresteki string, baştan itibaren kullanılırsa mantıklı. Hata mesajı var orada, haliyle o hata mesajının tamamını yazdırmak istersin, yarısından sonrasını değil.

 

[Mikro Step]

4079D704 adresindeki stringde ne yaziyor? Bakilmasi gereken adres burasi cunku.

 

[taydin]

O da yukarıdaki mesajda var. Oradaki ekran çıktısını göremiyor musun? 4079D704 adresi aşağıdaki stringin ortasına geliyor. Şu mesajda belirttim

ghidra disassembler sorunu

Mesela şu string İlgili kod spesifik olarak string'in ortalarından bir yerden alıyor. Bütün string'lerde bu durum yok. İstatistiğini bilmiyorum birçok doğru yerden adresi alınan string de görüyorum yanlış alınan da görüyorum. Her zaman hata 4 ün katı da değil. Bazan 2 kayma da olabiliyor...

mekatronik.org

 

[taydin]

Şu anda başka bir ihtimal aklıma geldi problem ile ilgili. Biraz daha bakayım sonra paylaşırım.

 

[Mikro Step]

4079D704 adresinde ne var hic vermedin ki. 4079d6dc adresindeki stringi verdin o da 4079D704 adresine ulasamiyor bile.

 

[taydin]

Yukarıdaki görüntüye bakarsan, orada string'in başlangıç adresi 4079d6dc. Orada bir tane de XREF verilmiş. 405b4e00 adresindeki fonksiyon, tam olarak 405b509c adresindeki bir komut ile 4079d704 adresine erişiyor. O adres de, gri renkli yazıda belirtildiği gibi bu stringin içindeki "failure" un "f" harfine işaret ediyor.

Yani fonksiyon "Retry block recover because of flash op failure ..." gibi bir string okuyacağına, "failure ..." diye bir stringi okuyor.

 

[Dede]

Acizane fikrim şöyle.
Siz bir kod derleyip hex oluşturun benzer şekilde ve disassembly yapmaya çalışın.
Sanırım buradan başlamak en doğrusu olur.

 

[taydin]

İşin tuhaf tarafı bu string böyle, ama çok sayıda doğru okuduğu, yani baştan okuduğu string de var. Offset de tamamen değişken, belli bir pattern bulamadım.

 

[taydin]

Acizane fikrim şöyle.
Siz bir kod derleyip hex oluşturun benzer şekilde ve disassembly yapmaya çalışın.
Sanırım buradan başlamak en doğrusu olur.

Bir programı kaynak koddan derleyip ghidra'ya yüklersen, hiçbir bilmece kalmıyor. Fonksiyon isimleri, değişken isimleri, programın boyutu, yükleme adresi, başlama noktası, her şey apaçık belli oluyor.

 

[Dede]

Bir programı kaynak koddan derleyip ghidra'ya yüklersen, hiçbir bilmece kalmıyor. Fonksiyon isimleri, değişken isimleri, programın boyutu, yükleme adresi, başlama noktası, her şey apaçık belli oluyor.

Derlediğin hex haline gelince de mi?

 

[taydin]

Derlediğin hex haline gelince de mi?

Hex'de gelmez, ama oradaki yapılar az çok belli olacak. Genelde ELF programlarda entry point 0x8000 adresi oluyor. Vektörler 0 adresinde oluyor. Her vektörün neyi temsil ettiği belli.

Ama bu DL3021 programında hiçbir şey belli değil. Hangi adrese yükleniyor, başlangıç noktası, program neresi, data neresi, vektör neresi belli değil. Ben şöyle ilerledim bunda:

Önce i.mx283 peripheral registerlerini çıkardım. Sonra bir python script yazım ghidra'da tanımladım. Böylece bu registerlerin nerede kullanıldığı ortaya çıktı. Sonra da clock yapılandırma registerlerinin kullanıldığı yeri tespit edip oradan da geriye doğru gide gide, başka hiç kimsenin çağırmadığı "top level" fonksiyonu buldum. Bunun init fonksiyonu olduğunu varsaydım. Ama tabi kesin birşey hala yok. Belki başka bir init fonksiyonu var ve adresi dinamik olarak belirleniyor. Veya bu bir RTOS ise o zaman bir sürü kesinlikle dönmeyen ve başkasının çağırmadığı fonksiyon olacak.

Neyse, sonra string'lere baka baka birkaç tane printf tarzı iş yapan fonksiyon tespit ettim. İşte bu fonksiyonlara giren stringlere bakıyorum şimdi. Kimisi assert, kimisi hata mesajı, kimisi debug log mesajı. Ama doğru offsetten başlamıyorlar.

 

[Mikro Step]

37444 eklentisine bak

Yukarıdaki görüntüye bakarsan, orada string'in başlangıç adresi 4079d6dc. Orada bir tane de XREF verilmiş. 405b4e00 adresindeki fonksiyon, tam olarak 405b509c adresindeki bir komut ile 4079d704 adresine erişiyor. O adres de, gri renkli yazıda belirtildiği gibi bu stringin içindeki "failure" un "f" harfine işaret ediyor.

Yani fonksiyon "Retry block recover because of flash op failure ..." gibi bir string okuyacağına, "failure ..." diye bir stringi okuyor.

Kafayi yiyecegim. verdigin string 4079d6dc adresinden basliyor.

30 tane karakter var orda, string adresine eklersek 4079d6dc + 1E = 4079D6FA yani gormeyi arzuladigim 4079D704 adresine daha ulasilamadi bile.

Senin icin sorun cozuldu ama bana da aci. 4079D704 adresinde nasil bir string var?

 

[taydin]

4079D704 - 4079d6dc = 0x28 = 40

"Retry" kelimesinin R sinden başlayıp 40 karakter ileri gidersen, "failure" un f sine ulaşıyorsun.

 

[taydin]

bir de 30 karakter yok. String daha uzun, ama işte ghidra sadece bir kısmını yazıp gerisini ... demiş. Ama 4079D704 gösterilenler arasında.

 

[Mikro Step]

Evet o kisim da kafa karistirici. Hex verileri sayinca 30 tane saydim.

 

[taydin]

Hmm evet şimdi şüphelendiğim şeyi destekleyen bir veri gördüm. String'i baştan başlayan, yani sorunsuz görünen bir printf call buldum. Fonksiyona format string'inde iki tane arguman vardı, %s ve %d. Ama printf fonksiyonuna sadece bir integer veriliyor argüman olarak. Demekki bu format string'i bu fonksiyona ait değil. Yani programın yükleme adresi doğru değil.

Bunda 64 MByte DRAM var ve 0x40000000 adresinden başlıyor. Ben de programın en baştan yükleneceğini varsayarak o şekilde yükledim. Programın kendisinde herşey relatif olduğu için kod işleyişinde bir sorun olmuyor, ama string yüklemelerinin yapıldığı değişkenlerde yazılı olan adresler MUTLAK adres.

Bu durumda benim farklı yükleme adresleri denemem lazım. Öyle bir adres bulacağım ki, bütün string'ler yerine oturacak