ReadyToRun .NET assembly'leri yine de temiz C#'a decompile ediliyor, çünkü IL hiçbir zaman kaldırılmıyor

dev.to'da yayımlanan bir yazı, ReadyToRun (R2R) .NET assembly'lerinin — uygulama başlangıcını hızlandırmak için kullanılan önceden derlenmiş ikili dosyaların — neden sıradan managed assembly'ler kadar kolay okunabilir C#'a decompile edildiğini ve önceden derlemeyi bir tür kod koruması olarak gören ekiplerin neden yanıldığını adım adım anlatıyor.

ReadyToRun gerçekte ne yapar

Standart bir .NET dağıtımında assembly, metadata artı Intermediate Language (IL) olarak gelir ve just-in-time derleyici her metodu ilk çalıştığında native makine koduna dönüştürür. ReadyToRun bu derlemeyi daha öne taşır: dev.to yazısına göre crossgen2 adlı bir araç JIT'i ahead of time çalıştırır ve ortaya çıkan native kodu assembly'nin içine gömer; böylece runtime başlangıçta JIT işini atlayabilir. .NET runtime kütüphaneleri bu şekilde dağıtılır ve geliştiriciler kendi uygulamaları ve container imajları için PublishReadyToRun=true ayarını yaparak bu yöntemi seçebilir.

İnsanlara önceden derlemenin aynı zamanda bir gizleme yöntemi olduğu izlenimini veren şey bu native koddur. Yazının ana noktası ise bunun doğru olmadığıdır.

İkili dosyanın içinde ne var

Bir R2R assembly, native kodu orijinal managed yapıların yerine değil, onlara ek olarak saklar. PE dosyası üç ilgili bölüm içerir: tipleri, metotları ve imzaları tanımlayan ve hiçbir şekilde değiştirilmeyen ECMA-335 metadata tabloları; hâlâ mevcut olan her metodun IL gövdeleri; ve runtime'ın bu kodu kullanmak için ihtiyaç duyduğu arama tablolarıyla birlikte önceden derlenmiş native kodu tutan bir ReadyToRun bölümü. CLI header'ın managed-native-header dizini üzerinden erişilebilen bir ReadyToRunHeader parçaları birbirine bağlar ve imajı R2R olarak işaretler.

Decompiler'lar native kodu neden yok sayar

Glass gibi bir decompiler, IL'den C#'ı yeniden oluşturarak çalışır. Yazının anlattığına göre araç, tip ve imza bilgisini geri kazanmak için metadata tablolarında gezinir, ardından her metodun IL gövdesini C#'a geri yükseltir. Önceden derlenmiş native kod kendi tablolarıyla ayrı bir bölümde yaşar ve decompiler ona hiçbakmaz; çünkü IL hâlâ her metodun eksiksiz, taşınabilir tanımıdır ve dosyada oradadır.

Pratik sonuç: bir R2R imajını açmak, düz, yalnızca JIT kullanılan bir assembly'yi açmaktan farksızdır. Aynı metadata, aynı IL, aynı C# çıktısı. Yani .NET runtime kütüphanelerinin kendisi, bir PublishReadyToRun uygulaması veya crossgen ile derlenmiş bir container imajı, hiçbir özel işlem gerektirmeden okunabilir.

Belirli bir assembly'nin düz IL değil de R2R olduğunu doğrulamak için yazı, ReadyToRun header'ı aramayı öneriyor — decompiler araçları bunu etiketler ve çoğu zaman bir R2R sürüm numarası gösterir — ya da ikili dosyanın crossgen2'den ya da bir PublishReadyToRun derlemesinden gelip gelmediğine bakmayı.

Gerçek istisna NativeAOT

R2R ile en sık karıştırılan teknoloji NativeAOT'tur ve yazı, bunun tam tersi şekilde davrandığının altını çiziyor. NativeAOT uygulamanın tamamını ne IL ne de kurtarılabilir managed metadata içeren bağımsız bir native çalıştırılabilir dosyaya derler; dolayısıyla bir IL decompiler'ının okuyacak bir şeyi yoktur. Sunulan hızlı test şöyle: bir araç dosyayı .NET assembly'si olarak yükleyebiliyorsa, o dosya managed'dır — düz IL veya R2R — ve decompile edilir. Eğer o sadece bir native ikili dosyaysa, NativeAOT'tur ve onu okumak decompiler yerine native bir disassembler'ın işidir.

Yazı ayrıca Glass'ın ücretsiz olduğunu, dolayısıyla tüm bunları gerçek bir R2R imajında doğrulamanın hiçbir maliyeti olmadığını belirtiyor.

Neden önemli

.NET kodu dağıtan ve onu gizlemek için ReadyToRun'a güvenen herkes için bu soruyu netleştiriyor: R2R bir başlangıç performansı özelliğidir, bir koruma mekanizması değildir. Decompiler'da yüklenen herhangi bir assembly okunabilir C# üretir; iş mantığı dahil. Gerçek bir gizlilik veya lisanslama kaygısı olan ekiplerin başka yerlere bakması gerekir — daha zor bir hedef için NativeAOT'a ya da IL'nin kendisine uygulanacak özel bir obfuscation aracına.

Madalyonun öteki yüzü ise diğer herkes için iyi haber. R2R performansa duyarlı dağıtımlarda yaygındır — runtime kütüphaneleri bu şekilde gelir — ve yazı, bunun şeffaflık açısından hiçbir maliyeti olmadığını gösteriyor. Elinize önceden derlenmiş bir assembly'nin geçmesi, kodun ne yaptığını anlamak, üçüncü taraf bir bağımlılığı denetlemek veya yol boyunca kaybedilmiş kaynak kodu geri kazanmak için bir engel değildir.