P
PwnLab.Me
Admin
- Katılım
- 21 Ocak 2024
- Mesajlar
- 202
- Tepkime puanı
- 9
- Puanları
- 18
M. Akil Gündoğan tarafından yazılmıştır.
Merhaba,
Bu yazımda temel anlamda tersine mühendislik nedir ve hangi alanları kapsar gibi konulara değinmenin yanı sıra, bir siber güvenlik araştırmacısını asıl ilgilendiren yazılımsal tersine mühendislikteki temel kavramlarından bahsetmeye çalışacağım. Bundan sonraki ilerleyen süreç içerisinde yayınlamayı planladığım yazılarda nasipse uygulamalı olarak anlatacağım şeyleri zihinsel anlamda sağlam bir yapıya oturtabilmemiz için birtakım temel kavramları mutlaka bilmemiz gerektiğini düşünüyorum.
Zira internette reverse engineering alanında araştırmalar yapmaya ilk başladığım zamanlarda rastladığım kaynakların ekserisi ya sadece uzmanlar için hazırlanmıştı ya da oldukça ağır bir dil kullanıyordu. Haliyle yanlış bir öğrenme metodu izlediğimi anlamam çok fazla zaman almadı, tez elden temel kavramları öğrenmeye başlarken buldum kendimi. Daha sonraları okduğum çeşitli dökümanlara tekrar baktığımda ise her şey daha anlaşılır hale gelmişti. Velhasıl kelam ufak bir anımı anlattıktan sonra, ben de Pwnlab.Me üzerinde yayınlayacağım ilk yazıda başkaları da bu sıkıntıları çekmesin diye temel kavramlardan başlamaya karar verdim.
Lafı daha fazla uzatıp makaleyi sıkıcı bir hale getirmek istemiyorum, buraya kadar sayfayı kapatmadan bana tahammül edebildiyseniz ayrıca teşekkür ediyorum
Tersine mühendislik aslen adından da anlayabileceğiniz üzere herhangi bir üretim veya geliştirme sürecinden geçen varlıkların bazı adımlar izlenerek nasıl çalıştığının anlaşılması sürecine deniliyor diyebiliriz. Günümüzde daha çok “program crackleme” ile özdeşleşmiş gibi gözükse de hayatın her yönünü kapsayan apayrı bir bilim dalı olarak görülmeli. Bir tamircinin bozuk televizyondaki sorunu anlama sürecinden, öğrencilerin problem sorularını çözerken izlediği yöntemlere kadar hepsi aslında birer ters mühendislik örneği olarak değerlendirilebilir.
Reverse engineering biraz eğip bükünce hayatın her alanını kapsayan bir şey olduğu için, biz işin teknik tarafını ele alacağımızdan;
şeklinde üç kategoriye odaklanarak bu yazımızı devam ettireceğiz.
Daha çok mühendislerin bildiği ve kullandığı, çoğunlukla geliştirme aşamalarında da kullanılan tekniklere benzer şekilde yürütülen sürece denilir. Örneğin birçoğumuz (en azından ben böyleydim) çocukken aldığımız oyuncakların ve teknolojik aletlerin içini açıp meraklı gözlerle bakmışızdır. Bu maceranın her ne kadar sonu ilgili elektronik eşyanın parçalanması veya elektrikle çarpılma şeklinde hüsranla bitse de aslında bilmeden yapmaya çalıştığımız şey o donanımın nasıl çalıştığını görmek.
Fiziksel anlamda elde edilen donanımın hangi şekilde tasarlandığı bilgisinin devre yollarının çıkartılarak izlenmesi, üzerinde kullanılan devre bileşenlerinin not edilmesi, teknolojinin zayıf ve avantajlı noktalarının anlaşılması ve karşı koyacak veya güçlendirecek yöntemlerin geliştirilmesi donanımsal ters mühendisliğin uygulanma şekillerinden birkaçı. Bu tarz tersine mühendislik süreçlerine genel itibariyle devletlerin yatırım yaptığını ve uyguladığını söyleyebiliriz. Savaşın kendisi zaten adil olmadığı gibi, mühendislik süreçlerinde de her zaman etiklikten bahsetmek gerekmiyor. Dışarıdan satın alınan birçok yeni nesil askeri teknoloji bu süreçler izlenerek yerlileştirilip, ülke ekonomisine ve ordusuna katkı sağlayacak şekilde geliştirilebiliyor.
Donanımsal tersine mühendisliğe en büyük örnek olarak, bilgisayar dünyası IBM tekelindeyken bir grup mühendisin Clean Room ve Chinese Wall yaklaşımını izleyerek IBM patentini ihlal etmeden uyumlu bir bilgisayar geliştirmeyi başarmasını gösterebiliriz. Columbia Data Products olarak bildiğimiz bu marka kısa zamanda daha uygun ve performanslı bilgisayarlar üreterek piyasanın önemli oyuncularından biri oldu. Hazır bahsi geçmişken şunu da belirtmekte yarar var, tersine mühendislik faaliyetleri yürütülerek yapılan teknoloji geliştirme faaliyetleri patent ve fikri haklar nedeniyle yasal anlamda çok büyük cezalar gerektiren suçlar teşkil edebilir. Burada mühendisler bu cezai sorumluluktan kurtulmak için Clean Room ve Chinese Wall metodu uygulayacak iki gruptan oluşan bir yol izlediler. Birinci grup IBM’in bilgisayarlarını donanımsal ve yazılımsal tersine mühendislik yöntemleriyle detaylıca incelerken; ikinci grup, birinci gruptakilerin anlattıklarına göre sıfırdan bir prototip geliştirdi. Böylece patent hakları ihlal edilmeden daha iyi bir ürün ortaya konulabildi.
Görsel 1 – Columbia Data Products tarafından “Clean Room” tersine mühendislik yöntemleri uygulanarak geliştirilen IBM PC klonu. / Resim Kaynağı: Vikipedi
Genel itibariyle donanımından ziyade tasarımsal anlamdaki gözlemlerden yararlanılarak bilgi etmeye yarayan yöntemlere tasarımsal tersine mühendislik diyebiliriz. Mesela bir cep telefonu firmasının rakibinin tasarımını analiz ederek daha gelişmiş bir modeli piyasaya sürmesi gibi. Veya II. Dünya Savaşı zamanında Sovyetler ve Naziler gibi dış politikada pek başarılı olmayan ülkeler tarafından izlenen askeri teknoloji kopyalama faaliyetleri de bu alana dahil edilebilir. Amerikan yapısı Bazooka’nın Naziler tarafından Panzerschreck olarak yeniden tasarlanması, Sovyetler tarafından Boeing B-29’lar incelenerek Tupolev Tu-4 uçaklarının yapılması tasarımsal anlamdaki reverse engineering’e örnek verilebilir.
Görsel 2 – Sovyet Sosyalist Cumhuriyetler Birliği’nin ABD yapımı Boeing B-29’ları tersine mühendislik yöntemleriyle kopyalayarak geliştirmiş oldukları Tupolev Tu-4. / Resim Kaynağı: Vikipedi
Bizi bir siber güvenlik meraklısı olarak daha çok ilgilendiren taraf yazılımsal anlamda yapılan reverse engineering faaliyetleri. Yazılımlara yapılan bu işlemler diğerlerinden farklı olarak sadece tasarımı kopyalamak amacıyla yapılmıyor, birçok alanda işimize yarıyor. Genel itibariyle kullanım alanlarından bahsedecek olursak;
• Programların lisans kontrollerinin atlanarak kırılması
• Zararlı yazılımların incelenmesi
• Hataların ve güvenlik zafiyetlerinin tespit edilmesi
• Programların algoritmalarının çıkarılması, çalışma mantıklarının anlaşılabilmesi
gibi hususlarda imdadımıza yazılımsal ters mühendislik yöntemleri koşuyor. Bu alanda çalışmalar yürütebilmek için “debugger, diassembler, decompiler, packer/unpacker, hex editör” gibi birtakım temel araçlarla haşir neşir olmanız gerekiyor. Bu araçların neler olduğuna ve kullanılabilecek alternatiflere de değinmeye başlayalım.
Diassembler: “İkili kod” yani “binary” halde bulunan yürütülebilir dosyaların insanların anlayabileceği Assembly diline dönüştürülmesini sağlayan programlara diassembler deniliyor. Çünkü “0’lar ve 1’ler” ile oluşan programları bu haliyle inceleyip çıkarımlarda bulunmamız neredeyse imkansız. Malware veya dosya analizlerinde bu aşama genellikle araçlar tarafından hedef programın kendisi yürütülmeden gerçekleştirildiği için statik analizin bir parçası denilebilir. Piyasada bulunan diassembler’lara örnek olarak IDA Pro, radare2 ve Ghidra’yı gösterebiliriz. Çoğu diassembler aracında programların ayrıca C/C++ dillerinde pseudocode şeklindeki hallerini elde etmek de mümkündür.
Görsel 3 – IDA Pro ile bir programı diassemble etmeye çalıştığınızda karşılaşacağınız görüntü. Burada programın akışını görüyorsunuz. Diğer “view” çeşitlerine tıkladığınızda programı daha farklı şekillerde de inceleyebilirsiniz.
Görsel 4 – NSA tarafından geliştirilen Ghidra ile bir programı analiz etmeye çalışınca karşılacağınız görüntü. En sevdiğim yanı pseudocode olarak çok iyi ve anlaşılır çıktılar sunması. IDA’ya güzel bir alternatif.
Debugger: Normal şartlarda yürütülebilir dosyalar diassembler’lar kullanılarak Assembly dilinde incelenebilir fakat yazılımlar kullanıcıdan alınan girdilere göre veya çalışma esnasında bile farklı davranışlara bürünebildiklerinden, tersine mühendislik aşamalarında debugger kullanmak gerekebiliyor. Aslen hata ayıklayıcı anlamına gelen debugger’lar, temelde programların işlemcideki yürütülmesi esnasındaki hallerini ekrana veren araçlardan ibaretler. CPU, FPU, Memory olmak üzere bunların dökümlerinden yararlanarak programları analiz ederiz. Karşımızdaki programlama dili ise yine işlemcinin iletişim kurduğu Assembly’dir.
Diyelim halihazırda elimizde bir program var ve bunun lisans kontrollerini atlatmak istiyoruz. Yapmamız gereken şey diassembler ile önce analiz edebiliyorsak bunun akışını analiz etmek ve kritik noktaları belirlemek. Daha sonra aktif olarak debugger’lar yardımıyla daha önce özenle seçtiğimiz yerleri bulup yamalar yaparak kontrolleri atlatabiliyoruz. İşte cracking dediğimiz şey bu. Aynı zamanda programı da anlık takip edebiliyoruz.
En çok kullanılan debuggerlar’a OllyDBg, x64dbg ve Immunity Debugger’ı örnek gösterebiliriz.
Görsel 5 – x64dbg ile bir programı debug etmeye çalıştığnızda karşılaşacağınız görüntü. CPU kısmındaki dil program x86 olduğu için x86 Intel Assembly. Kullanışlılık bakımından diğer rakiplerine kıyasla çok daha işlevsel bir hata ayıklayıcı olduğunu söyleyebilirim.
Görsel 6 – OllyDBg’ın modlu versiyonu olan OllyICE ile bir programı debug etmeye çalıştığınızda karşılaşacağınız görüntü. Immunity Debugger’da aşağı yukarı buna benzer bir görüntü sunuyor, zaten o da OllyDBg’ın modlanmış bir başka versiyonu.
Scanner: Genel itibariyle her program derlendiğinde, yazıldığı dilin kendisine ve sürümüne ait spesifik bazı özel girdileri içerisinde barındırır. Bu packlendiğinde (arşivlemenin biraz daha farklı olan hali, ilerleyen zamanlarda anlatılacak) geçerli. Yazılımsal anlamda bir tersine mühendislik aşamasına girişmeden hemen önce programın yazıldığı dili ve packlendiyse hangi packer kullanılarak bunun gerçekleştirildiğini öğrenmemiz oldukça önemli. Zira buna göre farklı farklı çalışma metodları belirlemek gerekiyor. “Scanner” araçları işte bahsettiğimiz özel girdileri kontrol ederek programların hangi dillerde yazıldığı veya hangi şekilde paketlendiği hakkında bizlerin bilgi edinmesini sağlıyor.
Genel itibariyle tersine mühendisler tarafından en çok kullanılan scanner yazılımlar ExeInfoPe ve Detect it Easy diyebilirim. Yine de bu ikisine çok bağlı kalmamak lazım zira her scanner doğru tespitlerde ne yazık ki bulunamayabiliyor. Aynı şekilde en bilinen scanner’lar bunlar oldukları için program tarafında çeşitli section’lar editlenerek önlemler de alınmış olabiliyor.
Görsel 7 – DiE, ExeInfoPE ve RDG ile programları scan etmeye çalışınca elde edeceğiniz çıktılara ait görüntü.
Decompiler: Normal şartlarda çoğu programlama dilinde geliştirilen programlar binary olarak derlenirken, bazı dillerde derleme aşaması gerçekleştirilmez veya ben uydurduğum bir kavramla yarı gerçekleştirilir. Bu dillerle yazılmış olan programların kodları “scanner” araçlar yardımıyla analiz edildikten sonra decompiler’lar yardımıyla doğrudan elde edilebilir. Örneğin .NET tabanlı geliştirilmiş application’lar benim tabirimle yarı derlense bile JIT adı verilen bir çalışma yöntemi izlediği için ek önlemler alınmadıysa kolayca kaynak koduna decompile edilebiliyor. Python, AutoIt gibi scripting amaçlı dillerde yazılan programlar ise zaten doğrudan bir yorumlayıcıya bağlı olarak çalıştığı için, elimizdeki “.exe” dosyasını parçalamak kodları görmemiz için yetiyor.
Halihazırda en bilinen örnekleri .NET tabanlı diller için DotPeek ve dnSpy iken, AutoIT için Exe2Aut diyebiliriz.
Görsel 8 – dnSpy ile .NET tabanlı bir dil kullanılarak yazılan programı decompile ettiğinizde karşılaşacağınız görüntü. Resimden de görebileceğiniz gibi herhangi bir önlem alınmadıysa kodları çok temiz bir şekilde elde edebiliyoruz.
Packer ve Unpacker: Çeşitli araçlar yardımıyla genellikle kopya koruma veya malware yazarları tarafından programların genel akışının öğrenilememesi istendiğinde yazılımlar packlenir. Packer’lar aslında mini bir arşiv gibi çalışır. Programın kendisinde ufak bir değişiklik yaparak işlemcide asıl yürütülecek kodların en başta değil de, çeşitli koşullar gerçekleştirildiğinde gerekli bellek alanlarına aktarılarak yürütülmesini sağlar. Arşivleyicinin biraz farklı hali gibi düşünebiliriz tabi. Bu tersine mühendislik süreçlerini hayli zorlaştırır çünkü disassemble ettiğinizde programın akışını doğru düzgün göremez, debuggerlarla incelemeye kalktığınızdaysa programın aslıyla alakasız bir sürü Assembly koduyla karşılaşırsınız.
İşte bu nedenle packlenen bir programla karşılaşırsanız, onu daha düzgün inceleybilmek için unpack yani packerdan kurtarmanız gerekir. Sık kullanılan packerlara ait (UPX, Aspack vb.) piyasada pek çok unpacker bulunabilse de ileri seviye Themida, VMProtect gibi çözümler söz konusu olunca iş manuel olarak debugger ile inceleyip bazı noktaları takip ederek unpack etmeye kalıyor. Bu şimdilik bu makalemizin konusu değil, ilerleyen zamanlarda bakmaya çalışacağız.
Görsel 9 – Popüler birkaç packer ve UPX ile packlenen dosyaları unpack etmek için kullanılan araç. Themida daha çok C/C++ ve diğer dillerde geliştirilen programlar için kullanılırken, .NET ile geliştirilen yazılımları korumak amacıyla genellikle geliştiriciler Smart Assembly kullanıyor. Aslen obfuscator olsa da packer gibi birtakım kullanım şekilleri de olabiliyor.
Hex editör: İkili yani binary halde bulunan programlar genellikle bilgisayar sistemlerinde onaltılık yani “hexadecimal” yapıda işlenir. Hex editörleri, programları işte tam da bu saf formatında inceleyebilmemize imkan tanır. Temelde bir metin editörü gibidir fakat farklıdır. Yeri gelir bunları kullanarak programın içerisinde aradığınız değerleri ve kısımları bulursunuz, yeri gelir o dosyanın gerçekten içinde neler saklandığını da anlamakta kullanabilirsiniz. Aynı şekilde bu editörler yardımıyla programları çeşitli şekillerde yamalamak da pek mümkündür.
En çok kullanılan hex editörlere örnek olarak HxD’yi gösterebiliriz.
Görsel 10 – HxD Editor ile herhangi bir dosyayı incelediğinizde bu tarz bir görüntüyle karşılaşırsınız. Burada gördükleriniz hexadecimal biçimde veriler ve bu verilerin decode edilmiş halidir.
Evet, bu yazımızda genel tersine mühendislik literatür kavramlarından ve bir siber güvenlik uzmanı/malware analist adayının bilmesi gereken temel software reversing araçlarına dair terimlerden bahsetmiş olduk. Makaleyi aslında daha uzun bir şekilde yazmayı planlıyordum fakat öğrenilebilirlik düzeyini düşürmemek için burada bitirmeye karar verdim. Eğer sonuna kadar sabırla okuyabildiyseniz, tersine mühendislik hakkındaki bazı temel bilgileri edindiniz ve başınızı bu karmaşıklıkta belaya sokarak ilk adımı atmış oldunuz. Umarım herkes için faydalı bir içerik olmuştur.
[TR] Tersine Mühendisliğe Giriş #1 – Temel Kavramlar
Merhaba,
Bu yazımda temel anlamda tersine mühendislik nedir ve hangi alanları kapsar gibi konulara değinmenin yanı sıra, bir siber güvenlik araştırmacısını asıl ilgilendiren yazılımsal tersine mühendislikteki temel kavramlarından bahsetmeye çalışacağım. Bundan sonraki ilerleyen süreç içerisinde yayınlamayı planladığım yazılarda nasipse uygulamalı olarak anlatacağım şeyleri zihinsel anlamda sağlam bir yapıya oturtabilmemiz için birtakım temel kavramları mutlaka bilmemiz gerektiğini düşünüyorum.
Zira internette reverse engineering alanında araştırmalar yapmaya ilk başladığım zamanlarda rastladığım kaynakların ekserisi ya sadece uzmanlar için hazırlanmıştı ya da oldukça ağır bir dil kullanıyordu. Haliyle yanlış bir öğrenme metodu izlediğimi anlamam çok fazla zaman almadı, tez elden temel kavramları öğrenmeye başlarken buldum kendimi. Daha sonraları okduğum çeşitli dökümanlara tekrar baktığımda ise her şey daha anlaşılır hale gelmişti. Velhasıl kelam ufak bir anımı anlattıktan sonra, ben de Pwnlab.Me üzerinde yayınlayacağım ilk yazıda başkaları da bu sıkıntıları çekmesin diye temel kavramlardan başlamaya karar verdim.
Lafı daha fazla uzatıp makaleyi sıkıcı bir hale getirmek istemiyorum, buraya kadar sayfayı kapatmadan bana tahammül edebildiyseniz ayrıca teşekkür ediyorum
Tersine mühendislik aslen adından da anlayabileceğiniz üzere herhangi bir üretim veya geliştirme sürecinden geçen varlıkların bazı adımlar izlenerek nasıl çalıştığının anlaşılması sürecine deniliyor diyebiliriz. Günümüzde daha çok “program crackleme” ile özdeşleşmiş gibi gözükse de hayatın her yönünü kapsayan apayrı bir bilim dalı olarak görülmeli. Bir tamircinin bozuk televizyondaki sorunu anlama sürecinden, öğrencilerin problem sorularını çözerken izlediği yöntemlere kadar hepsi aslında birer ters mühendislik örneği olarak değerlendirilebilir.
Reverse engineering biraz eğip bükünce hayatın her alanını kapsayan bir şey olduğu için, biz işin teknik tarafını ele alacağımızdan;
- Donanımsal Tersine Mühendislik
- Tasarımsal Tersine Mühendislik
- Yazılımsal Tersine Mühendislik
şeklinde üç kategoriye odaklanarak bu yazımızı devam ettireceğiz.
Donanımsal Tersine Mühendislik
Daha çok mühendislerin bildiği ve kullandığı, çoğunlukla geliştirme aşamalarında da kullanılan tekniklere benzer şekilde yürütülen sürece denilir. Örneğin birçoğumuz (en azından ben böyleydim) çocukken aldığımız oyuncakların ve teknolojik aletlerin içini açıp meraklı gözlerle bakmışızdır. Bu maceranın her ne kadar sonu ilgili elektronik eşyanın parçalanması veya elektrikle çarpılma şeklinde hüsranla bitse de aslında bilmeden yapmaya çalıştığımız şey o donanımın nasıl çalıştığını görmek.
Fiziksel anlamda elde edilen donanımın hangi şekilde tasarlandığı bilgisinin devre yollarının çıkartılarak izlenmesi, üzerinde kullanılan devre bileşenlerinin not edilmesi, teknolojinin zayıf ve avantajlı noktalarının anlaşılması ve karşı koyacak veya güçlendirecek yöntemlerin geliştirilmesi donanımsal ters mühendisliğin uygulanma şekillerinden birkaçı. Bu tarz tersine mühendislik süreçlerine genel itibariyle devletlerin yatırım yaptığını ve uyguladığını söyleyebiliriz. Savaşın kendisi zaten adil olmadığı gibi, mühendislik süreçlerinde de her zaman etiklikten bahsetmek gerekmiyor. Dışarıdan satın alınan birçok yeni nesil askeri teknoloji bu süreçler izlenerek yerlileştirilip, ülke ekonomisine ve ordusuna katkı sağlayacak şekilde geliştirilebiliyor.
Donanımsal tersine mühendisliğe en büyük örnek olarak, bilgisayar dünyası IBM tekelindeyken bir grup mühendisin Clean Room ve Chinese Wall yaklaşımını izleyerek IBM patentini ihlal etmeden uyumlu bir bilgisayar geliştirmeyi başarmasını gösterebiliriz. Columbia Data Products olarak bildiğimiz bu marka kısa zamanda daha uygun ve performanslı bilgisayarlar üreterek piyasanın önemli oyuncularından biri oldu. Hazır bahsi geçmişken şunu da belirtmekte yarar var, tersine mühendislik faaliyetleri yürütülerek yapılan teknoloji geliştirme faaliyetleri patent ve fikri haklar nedeniyle yasal anlamda çok büyük cezalar gerektiren suçlar teşkil edebilir. Burada mühendisler bu cezai sorumluluktan kurtulmak için Clean Room ve Chinese Wall metodu uygulayacak iki gruptan oluşan bir yol izlediler. Birinci grup IBM’in bilgisayarlarını donanımsal ve yazılımsal tersine mühendislik yöntemleriyle detaylıca incelerken; ikinci grup, birinci gruptakilerin anlattıklarına göre sıfırdan bir prototip geliştirdi. Böylece patent hakları ihlal edilmeden daha iyi bir ürün ortaya konulabildi.
Görsel 1 – Columbia Data Products tarafından “Clean Room” tersine mühendislik yöntemleri uygulanarak geliştirilen IBM PC klonu. / Resim Kaynağı: Vikipedi
Tasarımsal Tersine Mühendislik
Genel itibariyle donanımından ziyade tasarımsal anlamdaki gözlemlerden yararlanılarak bilgi etmeye yarayan yöntemlere tasarımsal tersine mühendislik diyebiliriz. Mesela bir cep telefonu firmasının rakibinin tasarımını analiz ederek daha gelişmiş bir modeli piyasaya sürmesi gibi. Veya II. Dünya Savaşı zamanında Sovyetler ve Naziler gibi dış politikada pek başarılı olmayan ülkeler tarafından izlenen askeri teknoloji kopyalama faaliyetleri de bu alana dahil edilebilir. Amerikan yapısı Bazooka’nın Naziler tarafından Panzerschreck olarak yeniden tasarlanması, Sovyetler tarafından Boeing B-29’lar incelenerek Tupolev Tu-4 uçaklarının yapılması tasarımsal anlamdaki reverse engineering’e örnek verilebilir.
Görsel 2 – Sovyet Sosyalist Cumhuriyetler Birliği’nin ABD yapımı Boeing B-29’ları tersine mühendislik yöntemleriyle kopyalayarak geliştirmiş oldukları Tupolev Tu-4. / Resim Kaynağı: Vikipedi
Yazılımsal Tersine Mühendislik
Bizi bir siber güvenlik meraklısı olarak daha çok ilgilendiren taraf yazılımsal anlamda yapılan reverse engineering faaliyetleri. Yazılımlara yapılan bu işlemler diğerlerinden farklı olarak sadece tasarımı kopyalamak amacıyla yapılmıyor, birçok alanda işimize yarıyor. Genel itibariyle kullanım alanlarından bahsedecek olursak;
• Programların lisans kontrollerinin atlanarak kırılması
• Zararlı yazılımların incelenmesi
• Hataların ve güvenlik zafiyetlerinin tespit edilmesi
• Programların algoritmalarının çıkarılması, çalışma mantıklarının anlaşılabilmesi
gibi hususlarda imdadımıza yazılımsal ters mühendislik yöntemleri koşuyor. Bu alanda çalışmalar yürütebilmek için “debugger, diassembler, decompiler, packer/unpacker, hex editör” gibi birtakım temel araçlarla haşir neşir olmanız gerekiyor. Bu araçların neler olduğuna ve kullanılabilecek alternatiflere de değinmeye başlayalım.
Diassembler: “İkili kod” yani “binary” halde bulunan yürütülebilir dosyaların insanların anlayabileceği Assembly diline dönüştürülmesini sağlayan programlara diassembler deniliyor. Çünkü “0’lar ve 1’ler” ile oluşan programları bu haliyle inceleyip çıkarımlarda bulunmamız neredeyse imkansız. Malware veya dosya analizlerinde bu aşama genellikle araçlar tarafından hedef programın kendisi yürütülmeden gerçekleştirildiği için statik analizin bir parçası denilebilir. Piyasada bulunan diassembler’lara örnek olarak IDA Pro, radare2 ve Ghidra’yı gösterebiliriz. Çoğu diassembler aracında programların ayrıca C/C++ dillerinde pseudocode şeklindeki hallerini elde etmek de mümkündür.
Görsel 3 – IDA Pro ile bir programı diassemble etmeye çalıştığınızda karşılaşacağınız görüntü. Burada programın akışını görüyorsunuz. Diğer “view” çeşitlerine tıkladığınızda programı daha farklı şekillerde de inceleyebilirsiniz.
Görsel 4 – NSA tarafından geliştirilen Ghidra ile bir programı analiz etmeye çalışınca karşılacağınız görüntü. En sevdiğim yanı pseudocode olarak çok iyi ve anlaşılır çıktılar sunması. IDA’ya güzel bir alternatif.
Debugger: Normal şartlarda yürütülebilir dosyalar diassembler’lar kullanılarak Assembly dilinde incelenebilir fakat yazılımlar kullanıcıdan alınan girdilere göre veya çalışma esnasında bile farklı davranışlara bürünebildiklerinden, tersine mühendislik aşamalarında debugger kullanmak gerekebiliyor. Aslen hata ayıklayıcı anlamına gelen debugger’lar, temelde programların işlemcideki yürütülmesi esnasındaki hallerini ekrana veren araçlardan ibaretler. CPU, FPU, Memory olmak üzere bunların dökümlerinden yararlanarak programları analiz ederiz. Karşımızdaki programlama dili ise yine işlemcinin iletişim kurduğu Assembly’dir.
Diyelim halihazırda elimizde bir program var ve bunun lisans kontrollerini atlatmak istiyoruz. Yapmamız gereken şey diassembler ile önce analiz edebiliyorsak bunun akışını analiz etmek ve kritik noktaları belirlemek. Daha sonra aktif olarak debugger’lar yardımıyla daha önce özenle seçtiğimiz yerleri bulup yamalar yaparak kontrolleri atlatabiliyoruz. İşte cracking dediğimiz şey bu. Aynı zamanda programı da anlık takip edebiliyoruz.
En çok kullanılan debuggerlar’a OllyDBg, x64dbg ve Immunity Debugger’ı örnek gösterebiliriz.
Görsel 5 – x64dbg ile bir programı debug etmeye çalıştığnızda karşılaşacağınız görüntü. CPU kısmındaki dil program x86 olduğu için x86 Intel Assembly. Kullanışlılık bakımından diğer rakiplerine kıyasla çok daha işlevsel bir hata ayıklayıcı olduğunu söyleyebilirim.
Görsel 6 – OllyDBg’ın modlu versiyonu olan OllyICE ile bir programı debug etmeye çalıştığınızda karşılaşacağınız görüntü. Immunity Debugger’da aşağı yukarı buna benzer bir görüntü sunuyor, zaten o da OllyDBg’ın modlanmış bir başka versiyonu.
Scanner: Genel itibariyle her program derlendiğinde, yazıldığı dilin kendisine ve sürümüne ait spesifik bazı özel girdileri içerisinde barındırır. Bu packlendiğinde (arşivlemenin biraz daha farklı olan hali, ilerleyen zamanlarda anlatılacak) geçerli. Yazılımsal anlamda bir tersine mühendislik aşamasına girişmeden hemen önce programın yazıldığı dili ve packlendiyse hangi packer kullanılarak bunun gerçekleştirildiğini öğrenmemiz oldukça önemli. Zira buna göre farklı farklı çalışma metodları belirlemek gerekiyor. “Scanner” araçları işte bahsettiğimiz özel girdileri kontrol ederek programların hangi dillerde yazıldığı veya hangi şekilde paketlendiği hakkında bizlerin bilgi edinmesini sağlıyor.
Genel itibariyle tersine mühendisler tarafından en çok kullanılan scanner yazılımlar ExeInfoPe ve Detect it Easy diyebilirim. Yine de bu ikisine çok bağlı kalmamak lazım zira her scanner doğru tespitlerde ne yazık ki bulunamayabiliyor. Aynı şekilde en bilinen scanner’lar bunlar oldukları için program tarafında çeşitli section’lar editlenerek önlemler de alınmış olabiliyor.
Görsel 7 – DiE, ExeInfoPE ve RDG ile programları scan etmeye çalışınca elde edeceğiniz çıktılara ait görüntü.
Decompiler: Normal şartlarda çoğu programlama dilinde geliştirilen programlar binary olarak derlenirken, bazı dillerde derleme aşaması gerçekleştirilmez veya ben uydurduğum bir kavramla yarı gerçekleştirilir. Bu dillerle yazılmış olan programların kodları “scanner” araçlar yardımıyla analiz edildikten sonra decompiler’lar yardımıyla doğrudan elde edilebilir. Örneğin .NET tabanlı geliştirilmiş application’lar benim tabirimle yarı derlense bile JIT adı verilen bir çalışma yöntemi izlediği için ek önlemler alınmadıysa kolayca kaynak koduna decompile edilebiliyor. Python, AutoIt gibi scripting amaçlı dillerde yazılan programlar ise zaten doğrudan bir yorumlayıcıya bağlı olarak çalıştığı için, elimizdeki “.exe” dosyasını parçalamak kodları görmemiz için yetiyor.
Halihazırda en bilinen örnekleri .NET tabanlı diller için DotPeek ve dnSpy iken, AutoIT için Exe2Aut diyebiliriz.
Görsel 8 – dnSpy ile .NET tabanlı bir dil kullanılarak yazılan programı decompile ettiğinizde karşılaşacağınız görüntü. Resimden de görebileceğiniz gibi herhangi bir önlem alınmadıysa kodları çok temiz bir şekilde elde edebiliyoruz.
Packer ve Unpacker: Çeşitli araçlar yardımıyla genellikle kopya koruma veya malware yazarları tarafından programların genel akışının öğrenilememesi istendiğinde yazılımlar packlenir. Packer’lar aslında mini bir arşiv gibi çalışır. Programın kendisinde ufak bir değişiklik yaparak işlemcide asıl yürütülecek kodların en başta değil de, çeşitli koşullar gerçekleştirildiğinde gerekli bellek alanlarına aktarılarak yürütülmesini sağlar. Arşivleyicinin biraz farklı hali gibi düşünebiliriz tabi. Bu tersine mühendislik süreçlerini hayli zorlaştırır çünkü disassemble ettiğinizde programın akışını doğru düzgün göremez, debuggerlarla incelemeye kalktığınızdaysa programın aslıyla alakasız bir sürü Assembly koduyla karşılaşırsınız.
İşte bu nedenle packlenen bir programla karşılaşırsanız, onu daha düzgün inceleybilmek için unpack yani packerdan kurtarmanız gerekir. Sık kullanılan packerlara ait (UPX, Aspack vb.) piyasada pek çok unpacker bulunabilse de ileri seviye Themida, VMProtect gibi çözümler söz konusu olunca iş manuel olarak debugger ile inceleyip bazı noktaları takip ederek unpack etmeye kalıyor. Bu şimdilik bu makalemizin konusu değil, ilerleyen zamanlarda bakmaya çalışacağız.
Görsel 9 – Popüler birkaç packer ve UPX ile packlenen dosyaları unpack etmek için kullanılan araç. Themida daha çok C/C++ ve diğer dillerde geliştirilen programlar için kullanılırken, .NET ile geliştirilen yazılımları korumak amacıyla genellikle geliştiriciler Smart Assembly kullanıyor. Aslen obfuscator olsa da packer gibi birtakım kullanım şekilleri de olabiliyor.
Hex editör: İkili yani binary halde bulunan programlar genellikle bilgisayar sistemlerinde onaltılık yani “hexadecimal” yapıda işlenir. Hex editörleri, programları işte tam da bu saf formatında inceleyebilmemize imkan tanır. Temelde bir metin editörü gibidir fakat farklıdır. Yeri gelir bunları kullanarak programın içerisinde aradığınız değerleri ve kısımları bulursunuz, yeri gelir o dosyanın gerçekten içinde neler saklandığını da anlamakta kullanabilirsiniz. Aynı şekilde bu editörler yardımıyla programları çeşitli şekillerde yamalamak da pek mümkündür.
En çok kullanılan hex editörlere örnek olarak HxD’yi gösterebiliriz.
Görsel 10 – HxD Editor ile herhangi bir dosyayı incelediğinizde bu tarz bir görüntüyle karşılaşırsınız. Burada gördükleriniz hexadecimal biçimde veriler ve bu verilerin decode edilmiş halidir.
Evet, bu yazımızda genel tersine mühendislik literatür kavramlarından ve bir siber güvenlik uzmanı/malware analist adayının bilmesi gereken temel software reversing araçlarına dair terimlerden bahsetmiş olduk. Makaleyi aslında daha uzun bir şekilde yazmayı planlıyordum fakat öğrenilebilirlik düzeyini düşürmemek için burada bitirmeye karar verdim. Eğer sonuna kadar sabırla okuyabildiyseniz, tersine mühendislik hakkındaki bazı temel bilgileri edindiniz ve başınızı bu karmaşıklıkta belaya sokarak ilk adımı atmış oldunuz. Umarım herkes için faydalı bir içerik olmuştur.
Moderatör tarafında düzenlendi:
