R-Studio için özel bir bilinen dosya türü oluşturma. İmzaya göre dosya türünü belirleme Dosya imzası nedir
Kavram " sihirli sayı"programlamada üç anlam vardır:
- Veri imzası
- Seçildi benzersiz değerler, diğer değerlerle aynı olmamalıdır (örn. UUID)
- Kötü programlama uygulaması.
Veri imzası
sihirli sayı, veya imza, - bir kaynağı veya veriyi benzersiz şekilde tanımlamak için kullanılan bir tam sayı veya metin sabiti. Böyle bir sayının kendi başına bir anlamı yoktur ve program kodunda uygun bağlam veya yorum olmadan görünmesi durumunda kafa karışıklığına neden olabilir; bunu bir başkasına, hatta yakın değere bile değiştirmeye çalışmak, tamamen öngörülemeyen sonuçlara yol açabilir. Bu nedenle bu tür sayılara ironik bir şekilde sihirli sayılar deniyordu. Şu anda bu isim bir terim olarak sağlam bir şekilde yerleşmiştir. Örneğin, derlenmiş herhangi bir Java dili sınıfı, onaltılık "sihirli sayı" 0xCAFEBABE ile başlar. Yaygın olarak bilinen ikinci örnek ise herhangi çalıştırılabilir dosya işletim sistemi Microsoft Windows.exe uzantılı, 0x4D5A bayt dizisiyle başlar (bu, MS-DOS'un yaratıcılarından biri olan Mark Zbikowski'nin baş harfleri olan MZ ASCII karakterlerine karşılık gelir). Daha az bilinen bir örnek, hata ayıklama modunda 0xDEADBEEF adresine sahip olan Microsoft Visual C++'daki (Microsoft Visual Studio'nun 2005 sürümünden beri) başlatılmamış işaretçidir.
UNIX benzeri işletim sistemleri Dosya türü genellikle adının uzantısına bakılmaksızın dosya imzasına göre belirlenir. Dosya imzasını yorumlamak için standart bir dosya yardımcı programı sağlarlar.
Kötü programlama uygulaması
Kaynak metinde sayısal bir değerin geçtiği ve bunun ne anlama geldiği açık olmadığında "sihirli sayılar" olarak da adlandırılan kötü bir programlama uygulamasıdır. Örneğin, Java ile yazılmış bunun gibi bir pasaj kötü olurdu:
DrawSprite(53, 320, 240);
final int SCREEN_WIDTH = 640; final int SCREEN_HEIGHT = 480; final int SCREEN_X_CENTER = SCREEN_WIDTH / 2; final int SCREEN_Y_CENTER = SCREEN_HEIGHT / 2; final int SPRITE_CROSSHAIR = 53; ... DrawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
Artık her şey açık: Bu çizgi ekranın ortasında bir hareketli grafik (görüntünün artı işareti) gösteriyor. Çoğu programlama dilinde bu tür sabitler için kullanılan tüm değerler derleme zamanında hesaplanacak ve değerlerin kullanıldığı yerlere yerleştirilecektir. Dolayısıyla kaynak metinde böyle bir değişiklik yapılması programın performansını düşürmez.
Ayrıca sihirli sayılar programdaki hataların potansiyel kaynağıdır:
- Aynı sihirli sayı bir programda birden fazla kullanılıyorsa (veya potansiyel olarak kullanılabilirse), o zaman bunu değiştirmek, her bir oluşumda düzenleme yapılmasını gerektirir (adlandırılmış sabitin değerinde yalnızca bir düzenleme yerine). Tüm oluşumlar düzeltilmezse en az bir hata oluşacaktır.
- Oluşan olayların en az birinde, sihirli sayı başlangıçta yanlış yazılmış olabilir ve bunun tespit edilmesi oldukça zordur.
- Sihirli sayı örtülü bir parametreye veya başka bir sihirli sayıya bağlı olabilir. Açıkça tanımlanmayan bu bağımlılıklar karşılanmazsa en az bir hata meydana gelecektir.
- Bir sihirli sayının oluşumlarını değiştirirken, bağımsız ancak aynı sayısal değere sahip başka bir sihirli sayıyı yanlışlıkla değiştirmek mümkündür.
Sihirli sayılar ve platformlar arası
Bazen sihirli sayılar platformlar arası kodlara zarar verir. Gerçek şu ki, C'de, 32 ve 64 bit işletim sistemlerinde char, short ve long long türlerinin boyutu garanti edilirken int, long, size_t ve ptrdiff_t boyutları değişebilir (ilk ikisi için, derleyici geliştiricilerinin tercihlerine bağlı olarak, son ikisi için - hedef sistemin bit kapasitesine bağlı olarak). Eski veya kötü yazılmış kodda, türün boyutunu belirten "sihirli sayılar" olabilir; farklı bit kapasitesine sahip makinelere geçerken ince hatalara yol açabilirler.
Örneğin:
const size_t NUMBER_OF_ELEMENTS = 10; uzun a[NUMBER_OF_ELEMENTS]; memset(a, 0, 10 * 4); // yanlış - long'un 4 bayt olduğu varsayılır, sihirli öğe sayısı kullanılır memset(a, 0, NUMBER_OF_ELEMENTS * 4); // yanlış - long'un 4 bayt olduğu varsayılıyor memset(a, 0, NUMBER_OF_ELEMENTS * sizeof(long)); // tamamen doğru değil - tür adının kopyası (tür değişirse, onu burada da değiştirmeniz gerekecektir) memset (a , 0 , NUMBER_OF_ELEMENTS * sizeof (a [ 0 ])); // doğru, sıfır olmayan boyuttaki dinamik diziler için en uygun memset(a, 0, sizeof(a)); // doğru, statik diziler için en uygun
Sihirli olmayan sayılar
Tüm sayıların sabitlere dönüştürülmesine gerek yoktur. Örneğin, kod
Bilinen türlerdeki dosyaları tarayarak arama yapın (veya sıklıkla söylendiği gibi, dosyaları imzaya göre arayın), R-Studio veri kurtarma yardımcı programında kullanılan en etkili yöntemlerden biridir. Belirli bir imzanın kullanılması, dizin yapısı ve dosya adlarına ilişkin bilgilerin kısmen veya tamamen eksik (hasarlı) olduğu durumlarda belirli türdeki dosyaları geri yüklemenize olanak tanır.
Tipik olarak disk bölümleme tablosu, dosyaların konumunu belirlemek için kullanılır. Bir diski bir kitapla karşılaştırırsanız bölüm tablosu içindekiler tablosuna benzer olacaktır. Tarama sırasında R-Studio, belirli belirli imzaları kullanarak disk bölüm tablosunda bilinen dosya türlerini arar. Bu, hemen hemen her dosya türünün benzersiz bir imzaya veya veri desenine sahip olmasıyla mümkün olmaktadır. Dosya imzaları, dosyanın başında belirli bir konumda ve çoğu durumda dosyanın sonunda da bulunur. Tarama sırasında R-Studio, bulunan verileri bilinen dosya türlerinin imzalarıyla eşleştirir, bu da bunların tanımlanmasına ve verilerinin kurtarılmasına olanak tanır.
Bilinen dosya türlerini tarama teknolojisini kullanan R-Studio, yeniden biçimlendirilmiş ve bölüm tablolarının üzerine yazılan disklerdeki verileri kurtarmanıza olanak tanır. Ayrıca, bir disk bölümünün üzerine yazılması, hasar görmesi veya silinmesi durumunda, bilinen dosya türlerinin taranması tek seçenektir.
Ancak hemen hemen her şeyin dezavantajları vardır ve R-Studio'da kullanılan bilinen dosya türleri de istisna değildir. Bu nedenle, bilinen dosya türlerini tararken, R-Studio yalnızca parçalanmamış dosyaları kurtarmanıza olanak tanır, ancak daha önce de belirtildiği gibi çoğu durumda bu mümkün olan en son yöntemdir.
R-Studio halihazırda en yaygın dosya türlerinin imzalarını içermektedir (görüntüle tam liste bilinen türlerdeki dosyalar R-Studio Çevrimiçi Yardım bölümünde bulunabilir.)
Gerektiğinde kullanıcı R-Studio'ya yeni dosya türleri ekleyebilir. Örneğin, benzersiz türde veya R-Studio'nun son yayın tarihinden sonra geliştirilen dosyaları bulmanız gerekiyorsa, bilinen türlerdeki dosyalara kendi imzalarınızı ekleyebilirsiniz. Bu süreç daha sonra tartışılacaktır.
Bilinen Türlerin Özel Dosyaları
Bilinen dosya türlerinin özel dosya imzaları, XML dosyası Ayarlar iletişim kutusunda belirtildi. İmza eklemek iki bölümden oluşur:
- Dosyanın başında ve varsa sonunda yer alan dosya imzasının belirlenmesi.
- Dosya imzasını ve dosya türüyle ilgili diğer bilgileri içeren bir XML dosyası oluşturun.
Bütün bunlar R-Studio kullanılarak yapılabilir. Aynı zamanda, XML belgelerini oluşturma (düzenleme) alanında veya onaltılık düzenleme alanında uzman olmanıza gerek yoktur - kullanıcının kendisine yönelik olan bu kılavuzda (makale) giriş seviyesi Bu sürecin tüm aşamaları detaylı olarak ele alınacaktır.
Örnek: MP4 dosyası için imza ekleme (XDCam-EX Codec)
Sony XDCAM-EX kullanılarak oluşturulan bir .MP4 dosyası örneğini kullanarak dosya imzası eklemeye bakalım. Örneğin, henüz bilgisayarınızın sabit diskine kaydetmeyi başaramadığınız dosyalar için SD kartın hasar görmesi durumunda kullanabilirsiniz.
Birinci Aşama: Dosya İmzasının Belirlenmesi
Dosya imzasını belirlemek için aynı formattaki dosya örneklerini göz önünde bulundurun.
Bunlar Sony XDCAM-EX'ten dört video dosyası olsun:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4
Göz önünde bulundurma kolaylığı açısından bunların küçük dosyalar olmasına izin verin. Daha büyük dosyaların onaltılık olarak görüntülenmesi daha zordur.
1. Dosyaları R-Studio'da açın. Bunu yapmak için her dosyaya sağ tıklayın ve içerik menüsünden Görüntüle/Düzenle'yi seçin.
2. Dosyaları karşılaştıralım. Dört dosyanın hepsinde bulunan aynı modeli arayacağız. O ortaya çıkacak dosya imzası. Genellikle dosya imzaları dosyanın başında bulunur, ancak bazen de sonunda bulunur.
3. Dosyanın başlangıcında dosya imzasını tanımlayın. Örneğimizde dosyanın en başında yer almaktadır. Bunun her zaman gerçekleşmediğini unutmayın; genellikle dosya imzası dosyanın başındadır, ancak ilk satırda değildir (offset).
Aşağıdaki resimlerden, dört dosyanın hepsinin içeriğinin farklı olduğu ancak hepsinin aynı dosya imzasıyla başladığı görülmektedir. 
Büyütmek için resme tıklayın
Büyütmek için resme tıklayın
Büyütmek için resme tıklayın
Büyütmek için resme tıklayın
Resimlerde vurgulanan alan bir dosya imzasıdır bu türden Dosyalar. Hem metin hem de onaltılık formatta sunulur.
Metin biçiminde dosya imzası şöyle görünür:
....ftypmp42....mp42.......ücretsiz
Noktalar (“.”), metin biçiminde temsil edilemeyen karakterleri belirtir. Bu nedenle, dosya imzasının onaltılık biçimini de sağlamak gerekir:
00 00 00 18 66 74 79 6D 70 34 32 00 00 00 00 6D 70 34 32 00 00 00 00 00 00 00 08 66 72 65 65
4. Aynı şekilde dosya imzasını da tanımlıyoruz ancak dosyanın en sonunda. Farklı bir dosya imzası, farklı bir uzunluk olabilir.
Aşağıdaki resimler dosyanın sonundaki dosya imzasını vurgulamaktadır: 
Büyütmek için resme tıklayın
Büyütmek için resme tıklayın
Büyütmek için resme tıklayın
Büyütmek için resme tıklayın
Seçilen alandan (dosya imzası) önceki verilerin dört dosyanın tamamında aynı olduğunu lütfen unutmayın. Bu bir dosya imzası olmayan teknik bilgidir ancak dört fotoğrafın (dosyanın) aynı parametrelerle aynı kamera kullanılarak çekildiğini gösterir. Teknik bilgilerle eşleşen kalıpları bir dosya imzasından ayırmak genellikle mümkündür. Örneğimizde, dosya imzasının başlangıcından önceki son satırda 'RecordingMode type=”normal”' metnini görüyoruz; bu, bunun bir imza değil, bir tür dosya parametresi olduğunu açıkça gösteriyor. Yanlışlıkla eklememek için bu satıra her zaman özellikle dikkat edin. teknik Bilgiler dosya imzasının bir parçası.
Bizim durumumuzda dosya imzası aşağıdaki metindir:
...
Noktaların metin biçiminde temsil edilemeyen karakterleri gösterdiğini hatırlatalım.
Onaltılı sistemde dosya imzası şöyle görünür:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Lütfen unutmayın: İmza her zaman dosyanın sonunda olmayacaktır.
İkinci Aşama: Bilinen Bir Dosya Türünü açıklayan XML dosyası oluşturma
Artık dosya imzasını tanımladıktan sonra bir XML dosyası oluşturabilir ve karşılık gelen dosya türünü R-Studio'ya dahil edebilirsiniz. Bu iki şekilde yapılabilir:
2.1 Yerleşik kullanımı grafik editörü dosya imzaları:
Araçlar menüsünden Ayarlar öğesini seçin, açılan Ayarlar iletişim kutusunda Bilinen Dosya Türleri sekmesini ve ardından Kullanıcının Dosya Türlerini Düzenle düğmesini tıklayın. 
Büyütmek için resme tıklayın
Kullanıcının Dosya Türlerini Düzenle iletişim kutusunda Dosya Türü Oluştur düğmesini tıklayın.
Aşağıdaki seçenekleri ayarlayın:
- Kimlik - benzersiz bir dijital tanımlayıcı. Bu numara rastgele seçilecek; Tek şey, başka herhangi bir dosya türünün dijital tanımlayıcısıyla eşleşmemesidir.
- Grup Açıklaması - bulunan dosyaların R-Studio'da bulunacağı grup. İkisini de ayarlayabilirsiniz yeni Grup veya halihazırda mevcut olanlardan birini seçin. Bizim için bu “Multimedya Video (Multimedya: Video)” grubu olacak.
- Tanım - Kısa Açıklama dosya tipi. Örneğimizde örneğin "Sony cam video, XDCam-EX" kullanabilirsiniz.
- Uzantı - bu türdeki dosyaların uzantısı. Bizim durumumuzda - mp4.
Özellikler parametresi isteğe bağlıdır, bizim durumumuzda onu kullanmamıza gerek yoktur. 
Büyütmek için resme tıklayın
Daha sonra başlangıç ve bitiş dosya imzasını girmeniz gerekir. Bunu yapmak için Başlat'ı seçin ve ardından içerik menüsüİmza Ekle komutu. 
Büyütmek için resme tıklayın
Daha sonra alana çift tıklayın<пустая сигнатура> (
Büyütmek için resme tıklayın
Ardından son dosya imzasını oluşturun. Kimden sütununa 21 girdiğinizden emin olun. 
Büyütmek için resme tıklayın
Bilinen dosya türleri için kendi imzanızı başarıyla oluşturdunuz.
Şimdi onu kaydetmeniz gerekiyor. Bunun iki yolu vardır: Kaydet düğmesini tıklatarak Ayarlar iletişim kutusunun Ana sekmesinde belirtilen varsayılan dosyaya kaydedebilirsiniz. Veya Farklı Kaydet... düğmesine tıklayın ve imzayı başka bir dosyaya kaydedin.
2.2 Bilinen Dosya Türünü açıklayan bir XML dosyasını manuel olarak oluşturma:
Oluşturmak için bu dosya XML sürüm 1.0 ve UTF-8 kodlamasını kullanalım. Ne olduğunu bilmiyorsanız umutsuzluğa kapılmayın; herhangi birini açın Metin düzeltici(örneğin, Notepad.exe) ve ilk satıra aşağıdaki metni girin:
Daha sonra dosya türünü (FileType) tanımlayan bir XML etiketi oluşturacağız. Daha önce açıklanan XML nitelikleri dikkate alındığında etiket şu şekilde görünecektir:
Hemen sonra ekleyelim
Daha sonra dosya imzasını (etiket) tanımlarız.
Varsa, bitiş imzasını da tanımlamanız gerekir (dosyanın sonunda). Bu aynı etiketi kullanır, ancak bir "from" öğesi ve bir "end" özelliği içerir. Bunun gibi görünecek:
Son dosya imzasının metin olmayan karakterler içermediğini, ancak eğik çizgi ve üçgen parantez içerdiğini unutmayın. XML söz dizimindeki karışıklığı ve hataları önlemek için imzadaki "/", " karakterlerini değiştireceğiz<" и ">" onaltılık değerleri.
Sonunda, dosya imzalarından sonra FileType ve FileTypeList kapanış etiketleri bulunmalıdır:
Yani dosyanın tamamı şöyle görünmeli:
Unutmayın: XML sözdizimi büyük/küçük harfe duyarlıdır, dolayısıyla doğru etiket şu şekilde olacaktır:
Dosyayı .xml uzantısıyla metin formatında kaydedelim. Örneğin: SonyCam.xml.
Bilinen dosya türleri için kendi imzamızı başarıyla oluşturduk. Bu örnek, özel bir dosya türü oluşturmanın temel ilkelerini anlamak için oldukça yeterlidir. Daha deneyimli kullanıcılar XML 2.0 sürümünü kullanabilir. Bununla ilgili daha fazla bilgiyi R-Studio çevrimiçi Yardım bölümünde okuyabilirsiniz.
3. Adım: Bilinen Bir Dosya Türünü Açıklayan Bir Dosyayı Kontrol Etme ve Ekleme
Bir sonraki adım, XML dosyanızı R-Studio'ya eklemek (yüklemek) olacaktır. Bu durumda otomatik olarak kontrol edilecektir.
Önceki aşamada oluşturduğumuz XML dosyasını R-Studio'ya yükleyelim. Bunu yapmak için Araçlar menüsündeki Ayarlar öğesini seçin. Ayarlar iletişim kutusunun Ana sekmesindeki Kullanıcı dosya türleri alanına, oluşturduğumuz XML dosyasını (SonyCam.xml) ekleyin. Uygula düğmesini tıklayın. 
Büyütmek için resme tıklayın
2. Yeni bir dosya türü indirme isteğine Evet yanıtını verin. 
Büyütmek için resme tıklayın
3. Dosya türünün başarıyla yüklendiğini doğrulamak için Ayarlar iletişim kutusunun Bilinen Dosya Türleri sekmesine tıklayın. Dosya türünü Multimedya Video grubuna (Multimedya: Video) eklediğimizi unutmayın. Bu grubu (klasörü) genişlettiğimizde, XML dosyasını oluştururken belirttiğimiz açıklamaya sahip bir öğe görmeliyiz: Sony cam video, XDCam-EX (.mp4). 
Büyütmek için resme tıklayın
Büyütmek için resme tıklayın
Dosya sözdiziminde herhangi bir hata varsa ilgili bir mesaj göreceksiniz: 
Büyütmek için resme tıklayın
Bu durumda XML dosyanızda hatalar olup olmadığını tekrar kontrol edin. Unutmayın: XML sözdizimi büyük/küçük harfe duyarlıdır ve her etiketin sonunda bir kapanış etiketi bulunmalıdır.
Adım 4: Bilinen Bir Dosya Türünü Açıklayan Dosyayı Test Etme
Oluşturduğumuz özel dosya türünün doğruluğunu kontrol etmek için çıkarılabilir bir USB flash sürücüde .mp4 dosyalarımızı bulmayı deneyelim.
1. Windows Vista veya Windows 7 altında, diski tam (hızlı değil) biçimlendirin veya bir disk alanı temizleme yardımcı programı (örneğin, R-Wipe & Clean) kullanın. tamamen kaldırma Diskte bulunan tüm veriler. İzin vermek USB diski FAT32 formatında biçimlendirilmiştir (aranan dosyaların boyutu 2 GB'ı geçmez).
2. Haydi kopyalayalım test dosyalarıÖnbellek içeriğinin diske kaydedilmesi için diske aktarın ve bilgisayarı yeniden başlatın. Ayrıca devre dışı bırakabilirsiniz Harici Sürücü ve ardından tekrar bağlayın.
3. İşletim sisteminde sürücü, örneğin mantıksal sürücü F:\ olarak tanımlanacaktır.
4. R-Studio'yu başlatalım. Sürücümüzü seçin (F:\) ve Tara düğmesine tıklayın 
Büyütmek için resme tıklayın
5. Tara iletişim kutusundaki (Dosya Sistemi) alanında Değiştir... düğmesine tıklayın ve tüm kutuların işaretini kaldırın. Bu şekilde bölüm tablosunu kullanarak dosya sistemlerini ve dosyaları aramayı devre dışı bırakacağız. 
Büyütmek için resme tıklayın
6. Bilinen Dosya Türleri İçin Ekstra Arama onay kutusunu işaretleyin. Bu, R-Studio'nun tarama sırasında bilinen dosya türlerini aramasına olanak tanır.
7. Taramayı başlatmak için Tara düğmesini tıklayın.
8. R-Studio diski tararken bekleyelim. Tarama Bilgileri sekmesi tarama ilerlemesini (ilerleme durumunu) gösterecektir. 
Büyütmek için resme tıklayın
9. Tarama tamamlandıktan sonra Ekstra Bulunan Dosyalar öğesini seçin ve üzerine çift tıklayın. 
Büyütmek için resme tıklayın
10. Test dosyalarımız Sony cam videosu, XDCam-EX klasöründe (veya İkinci Aşamada belirtilen dosya türü açıklamasına karşılık gelen başka bir isme sahip bir klasörde) bulunacaktır. 
Büyütmek için resme tıklayın
Dosya adlarının, tarihlerin ve konumların (klasörler) geri yüklenmediğini görüyorsunuz çünkü bu bilgi dosya sisteminde saklanır. Bu nedenle, R-Studio her dosyayı otomatik olarak yeni bir adla görüntüleyecektir.
Ancak dosyaların içeriğinin zarar görmediği açıktır. Bunu doğrulamak için bunları uygun programda, örneğin VLC media player'da açalım. 
Büyütmek için resme tıklayın
Çözüm
R-Studio'nun bilinen dosya türlerini tarama yeteneği, dosya sistemlerinin üzerine yazılan bir diskten bile verileri kurtarmanıza olanak tanır. İmzalarını kullanarak dosyaları oldukça etkili bir şekilde arayabilirsiniz; bu, örneğimizde olduğu gibi, geri yüklenen dosyaların türünü tam olarak biliyorsanız özellikle kullanışlıdır. Özel dosya türleri oluşturma yeteneği, belirli bir dosya imzasına sahip herhangi bir dosyayı bilinen dosya türleri listesine eklemenizi sağlar.
Çoğu kişi rarjpeg gibi dosyaları duymuş olabilir. Bu, jpeg görüntüsü ve birbirine yakın şekilde yapıştırılmış bir rar arşivinden oluşan özel bir dosya türüdür. Bilgi aktarma gerçeğini gizlemek için mükemmel bir kaptır. Kullanarak bir rarjpeg oluşturabilirsiniz. aşağıdaki komutlar:
UNIX: kedi image1.jpg archive.rar > image2.jpg
PENCERELER: kopyala /b image1.jpg+archive.rar image2.jpg
Veya bir hex düzenleyiciniz varsa.
Elbette bilgi aktarma gerçeğini gizlemek için yalnızca JPEG formatını değil, diğer birçok formatı da kullanabilirsiniz. Her formatın kendine has özellikleri vardır ve bu nedenle konteyner rolüne uygun olabilir veya olmayabilir. Yapıştırılan dosyaları en popüler formatlarda nasıl bulabileceğinizi veya yapıştırma gerçeğini nasıl belirtebileceğinizi anlatacağım.
Birleştirilmiş dosyaları tespit etme yöntemleri üç gruba ayrılabilir:
- EOF işaretleyicisinden sonraki alanı kontrol etme yöntemi. Pek çok popüler dosya biçiminde, istenen verilerin görüntülenmesinden sorumlu olan, dosya sonu işaretçisi adı verilen bir işaret bulunur. Örneğin, fotoğraf görüntüleyiciler bu işaretleyiciye kadar olan tüm baytları okur ancak bundan sonraki alan göz ardı edilir. Bu yöntem şu formatlar için idealdir: JPEG, PNG, GIF, ZIP, RAR, PDF.
- Dosya boyutunu kontrol etme yöntemi. Bazı formatların (ses ve video kapları) yapısı, gerçek dosya boyutunu hesaplamanıza ve bunu orijinal boyutla karşılaştırmanıza olanak tanır. Formatlar: AVI, WAV, MP4, MOV.
- CFB dosyalarını kontrol etme yöntemi. CFB veya Bileşik Dosya İkili Formatı, Microsoft tarafından geliştirilen, kendi dosya sistemine sahip bir konteyner olan bir belge formatıdır. Bu yöntem bir dosyadaki anormalliklerin tespit edilmesine dayanmaktadır.
Bir dosyanın bitiminden sonra hayat var mı?
JPEG
Bu sorunun cevabını bulmak için birleştirilmiş dosyaların “atası” olan formatın özelliklerini derinlemesine araştırmak ve yapısını anlamak gerekir. Herhangi bir JPEG, 0xFF 0xD8 imzasıyla başlar.Bu imzanın ardından servis bilgisi, isteğe bağlı olarak bir görüntü simgesi ve son olarak sıkıştırılmış görüntünün kendisi gelir. Bu formatta görüntünün sonu iki baytlık 0xFF 0xD9 imzasıyla işaretlenir.
PNG
PNG dosyasının ilk sekiz baytı şu imzayla kaplıdır: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Veri akışını sonlandıran imzayı sonlandırın: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.RAR'lar
Tüm rar arşivleri için ortak imza: 0x52 0x61 0x72 0x21 (Rar!). Ardından arşiv versiyonu ve diğer ilgili veriler hakkında bilgi gelir. Arşivin 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46 imzasıyla bittiği deneysel olarak belirlendi.Format tablosu ve imzaları:
Bu formatlarda yapıştırmayı kontrol etme algoritması son derece basittir:
- İlk imzayı bulun;
- Son imzayı bulun;
- Son imzadan sonra veri kalmamışsa dosyanız temizdir ve ek içermemektedir! Aksi halde son imzadan sonra başka formatlara bakmak gerekir.
GIF ve PDF
Bir PDF belgesinde, örneğin yanlış belge oluşturulması nedeniyle birden fazla EOF işaretçisi bulunabilir. Bir GIF dosyasındaki son imzaların sayısı, içindeki karelerin sayısına eşittir. Bu formatların özelliklerine dayanarak, ekli dosyaların varlığını kontrol etme algoritmasını geliştirmek mümkündür.- 1. nokta önceki algoritmadan tekrarlanır.
- 2. nokta önceki algoritmadan tekrarlanır.
- Son imzayı bulduğunuzda yerini hatırlayın ve daha ileriye bakın;
- Bu şekilde son EOF işaretçisine ulaşırsanız dosya temizdir.
- Dosya bir bitiş imzasıyla bitmiyorsa, goto, bulunan son son imzanın konumudur.
Posta Kodu
ZIP arşivlerinin özelliği üç farklı imzanın bulunmasıdır: Arşivin yapısı aşağıdaki gibidir:| Yerel Dosya Başlığı 1 |
| Dosya Verileri 1 |
| Veri Tanımlayıcı 1 |
| Yerel Dosya Başlığı 2 |
| Dosya Verileri 2 |
| Veri Tanımlayıcı 2 |
| ... |
| Yerel Dosya Başlığı |
| Dosya Verileri n |
| Veri Tanımlayıcısı n |
| Arşiv şifre çözme başlığı |
| Ekstra veri kaydını arşivle |
| Merkezi dizin |
Bir ZIP arşivini kontrol etmek için merkezi dizinin son imzasını bulmanız, 18 baytı atlamanız ve yorum alanında bilinen formatların imzalarını aramanız gerekir. Büyük beden Yorum aynı zamanda yapıştırma gerçeğini de gösteriyor.
Boyut önemlidir
AVİ
Bir AVI dosyasının yapısı şu şekildedir: her dosya bir RIFF imzasıyla başlar (0x52 0x49 0x46 0x46). Bayt 8'de formatı belirten bir AVI imzası vardır (0x41 0x56 0x49 0x20). 4 bayttan oluşan ofset 4'teki blok, veri bloğunun başlangıç boyutunu içerir (bayt sırası - küçük endian). Bir sonraki boyutu içeren blok numarasını bulmak için başlık boyutunu (8 bayt) ve 4-8 baytlık blokta elde edilen boyutu eklemeniz gerekir. Bu, toplam dosya boyutunu hesaplar. Hesaplanan boyutun gerçek dosya boyutundan daha küçük olması kabul edilebilir. Boyut hesaplandıktan sonra dosya yalnızca sıfır bayt içerecektir (1Kb sınırını hizalamak için gereklidir).Boyut hesaplama örneği:
WAV
AVI gibi, bir WAV dosyası da bir RIFF imzasıyla başlar, ancak bu dosyanın bayt 8 - WAVE'den (0x57 0x41 0x56 0x45) bir imzası vardır. Dosya boyutu AVI ile aynı şekilde hesaplanır. Gerçek boyut, hesaplanan boyutla tamamen eşleşmelidir.MP4
MP4 veya MPEG-4, video ve ses akışlarını depolamak için kullanılan ve ayrıca altyazıların ve görüntülerin depolanmasını da sağlayan bir medya taşıyıcı formatıdır.4 bayt uzaklığında imzalar vardır: dosya türü ftyp (66 74 79 70) (QuickTime Konteyner Dosya Türü) ve dosya alt türü mmp4 (6D 6D 70 34). Tanınma için gizlenmiş dosyalar, dosya boyutunu hesaplama yeteneğiyle ilgileniyoruz.
Bir örneğe bakalım. İlk bloğun boyutu sıfır uzaklığındadır ve 28'dir (00 00 00 1C, Big Endian bayt sırası); aynı zamanda ikinci veri bloğunun boyutunun bulunduğu uzaklığı da gösterir. 28 uzaklığında bir sonraki blok boyutunun 8'e eşit olduğunu görüyoruz (00 00 00 08). Bir sonraki blok boyutunu bulmak için, bulunan önceki blokların boyutlarını eklemeniz gerekir. Böylece dosya boyutu hesaplanır:
MOV
Yaygın olarak kullanılan bu format aynı zamanda bir MPEG-4 kabıdır. MOV, tescilli bir veri sıkıştırma algoritması kullanır, MP4'e benzer bir yapıya sahiptir ve aynı amaçlarla kullanılır - ses ve video verilerinin yanı sıra ilgili materyalleri depolamak için.MP4 gibi, herhangi bir mov dosyasının konum 4'te 4 baytlık bir ftyp imzası vardır, ancak bir sonraki imza qt__ (71 74 20 20) değerine sahiptir. Dosya boyutunu hesaplama kuralı değişmedi: dosyanın başından başlayarak bir sonraki bloğun boyutunu hesaplayıp topluyoruz.
Bu format grubunu "yapışkan" dosyaların varlığı açısından kontrol etmenin yöntemi, boyutu yukarıda belirtilen kurallara göre hesaplamak ve bunu kontrol edilen dosyanın boyutuyla karşılaştırmaktır. Geçerli dosya boyutu hesaplanandan çok daha küçükse, bu yapıştırma gerçeğini gösterir. AVI dosyalarını kontrol ederken, kenarlığı hizalamak için eklenen sıfırların varlığı nedeniyle hesaplanan boyutun dosya boyutundan daha küçük olabileceği kabul edilir. Bu durumda hesaplanan dosya boyutundan sonra sıfır olup olmadığını kontrol etmek gerekir.
Bileşik Dosya İkili Formatının Kontrol Edilmesi
Microsoft tarafından geliştirilen bu dosya formatı aynı zamanda OLE (Object Linking and Embedding) veya COM (Component Object Model) olarak da bilinmektedir. DOC, XLS, PPT dosyaları CFB formatları grubuna aittir.Bir CFB dosyası, 512 baytlık bir başlıktan ve veri akışlarını veya hizmet bilgilerini depolayan eşit uzunlukta sektörlerden oluşur. Özel sayılar haricinde her sektörün kendi negatif olmayan numarası vardır: “-1” - serbest sektörü numaralandırır, “-2” - zinciri kapatan sektörü numaralandırır. Tüm sektör zincirleri FAT tablosunda tanımlanmıştır.
Bir saldırganın belirli bir .doc dosyasını değiştirdiğini ve sonuna başka bir dosya yapıştırdığını varsayalım. Birkaç tane var çeşitli şekillerde belgede bir anormalliği tespit edin veya belirtin.
Anormal dosya boyutu
Yukarıda belirtildiği gibi, herhangi bir CFB dosyası bir başlık ve eşit uzunlukta sektörlerden oluşur. Sektör boyutunu bulmak için dosyanın başlangıcından itibaren 30 ofsetinde iki baytlık bir sayı okumanız ve bu sayının üssünü 2'ye yükseltmeniz gerekir. Bu sayı sırasıyla 9 (0x0009) veya 12'ye (0x000C) eşit olmalıdır; dosya sektörü boyutu 512 veya 4096 bayttır. Sektörü bulduktan sonra aşağıdaki eşitliği kontrol etmeniz gerekir:(DosyaBoyutu - 512) mod SektörBoyutu = 0
Bu eşitlik sağlanmazsa, dosyaların yapıştırılması gerçeğine dikkat çekebilirsiniz. Ancak bu yöntemin önemli bir dezavantajı vardır. Bir saldırgan sektör boyutunu biliyorsa, yapıştırılan verinin boyutu sektör boyutunun katı olacak şekilde dosyasını ve başka bir n baytı yapıştırması yeterlidir.
Bilinmeyen sektör türü
Saldırgan önceki kontrolü atlayacak bir yöntem biliyorsa, o zaman Bu method Tanımsız türlere sahip sektörlerin varlığını tespit edebilir.Eşitliği tanımlayalım:
FileSize = 512 + CountReal * SectorSize, burada FileSize dosya boyutu, SectorSize sektör boyutu, CountReal ise sektör sayısıdır.
Ayrıca aşağıdaki değişkenleri de tanımlıyoruz:
- CountFat – FAT sektörlerinin sayısı. Dosyanın başlangıcından itibaren 44. ofsette bulunur (4 bayt);
- CountMiniFAT – MiniFAT sektörlerinin sayısı. Dosyanın başlangıcından itibaren 64. ofsette bulunur (4 bayt);
- CountDIFAT – DIFAT sektörlerinin sayısı. Dosyanın başlangıcından itibaren 72. konumda bulunur (4 bayt);
- CountDE – Dizin Girişi sektörlerinin sayısı. Bu değişkeni bulmak için, 48 uzaklığında bulunan ilk DE sektörünü bulmanız gerekir. Daha sonra FAT'tan DE'nin tam bir temsilini almak ve DE sektörlerinin sayısını saymak gerekir;
- CountStreams – veri akışlarına sahip sektörlerin sayısı;
- CountFree – serbest sektörlerin sayısı;
- CountClassified – belirli bir türe sahip sektörlerin sayısı;
Açıkçası, eğer CountClassified ve CountReal eşit değilse, dosyaların birleştirilebileceği sonucuna varabiliriz.
Patronum bana oldukça ilginç bir görev verdi. Kısa sürede imzalara dayalı olarak virüs gövdelerini bulabilecek ve kullanılan paketleyici/şifreleyiciyi belirleyebilecek yürütülebilir bir dosya analizörü yazın. Bitmiş prototip birkaç saat içinde ortaya çıktı.
Yazarın sözü
İmza analizi
İmzaları kullanarak kötü amaçlı bir nesneyi aramak, herhangi bir antivirüsün yapabileceği bir şeydir. Genel olarak imza, taranan dosyanın bir virüs ve iyi tanımlanmış bir virüs olduğunun belirlenebilmesini sağlayan belirli özelliklerin resmileştirilmiş bir açıklamasıdır.
Burada çeşitli teknikler var. Bir alternatif, kötü amaçlı bir nesnenin N baytından oluşan bir imza kullanmaktır. Bu durumda, aptalca bir karşılaştırma değil, bazı maskeler kullanarak bir karşılaştırma yapabilirsiniz (EB ?? ?? CD 13 baytlarını aramak gibi). Veya "şu ve bu baytların programın giriş noktasında olması gerekir" gibi ek koşullar belirleyin. Kötü amaçlı yazılımın imzası özel bir konudur.
Aynı şekilde, yürütülebilir dosyanın bir veya başka bir kriptolayıcı veya paketleyici (örneğin, banal ASPack) tarafından paketlendiğinin belirlenebileceği bazı işaretler açıklanmaktadır. Dergimizi dikkatlice okursanız, kendisine aktarılan PE dosyası için en sık kullanılan paketleyicileri, kriptolayıcıları ve derleyicileri (veritabanında çok sayıda imza vardır) tanımlayabilen PEiD gibi bir aracı kesinlikle duymuşsunuzdur. . Ne yazık ki, programın yeni sürümleri uzun süredir yayınlanmadı ve yakın zamanda resmi web sitesinde projenin daha fazla gelişmeyeceğine dair bir mesaj belirdi. Yazık çünkü PEiD'nin yetenekleri (özellikle eklenti sistemi göz önüne alındığında) benim için çok faydalı olabilir. Kısa bir analizden sonra bunun bir seçenek olmadığı ortaya çıktı. Ancak İngilizce blogları araştırdıktan sonra bana uygun olanı hızla buldum. YARA Projesi (code.google.com/p/yara-project).
YARA nedir?
En başından beri, İnternet'in bir yerinde, belirli bir imza ile incelenen dosya arasındaki yazışmayı belirleme görevini üstlenecek açık kaynaklı bir geliştirmenin zaten bulunduğuna ikna olmuştum. Eğer böyle bir proje bulabilirsem, o zaman kolaylıkla bir web uygulamasının rayına konulup, oraya farklı imzalar eklenebilir ve benden istenileni alabilirim. YARA projesinin açıklamasını okuyunca plan daha da gerçekçi gelmeye başladı.
Geliştiriciler bunu, kötü amaçlı yazılım araştırmacılarının kötü amaçlı örnekleri tanımlamasına ve sınıflandırmasına yardımcı olacak bir araç olarak konumlandırıyor. Araştırmacı aşağıdakiler için açıklamalar oluşturabilir: farklı şekiller Kötü amaçlı yazılımın resmileştirilmiş özelliklerini tanımlayan metin veya ikili kalıpları kullanan kötü amaçlı yazılım. İmzalar bu şekilde alınıyor. Aslında her açıklama, analizcinin tetikleme mantığının belirlendiği bir dizi satırdan ve bazı mantıksal ifadelerden oluşur.
İncelenen dosya için kurallardan birinin koşulları karşılanıyorsa buna göre belirlenir (örneğin falan solucan). Neden bahsettiğimizi anlamak için basit bir kural örneği:
kural sessiz_banker: bankacı
{
meta:
açıklama = "Bu sadece bir örnek"
iş parçacığı_seviyesi = 3
in_the_wild = doğru
Teller:
$a = (6A 40 68 00 30 00 00 6A 14 8D 91)
$b = (8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9)
$c = "UVODFRYSIHLNWPEJXQZAKCBGMT"
durum:
$a veya $b veya $c
}
Bu kuralda YARA'ya, $a, $b, $c değişkenlerinde açıklanan örnek dizilerden en az birini içeren herhangi bir dosyanın, sessiz_banker truva atı olarak sınıflandırılması gerektiğini söyleriz. Ve bu çok basit bir kuraldır. Gerçekte kurallar çok daha karmaşık olabilir (bunun hakkında aşağıda konuşacağız).
Onu kullanan projelerin listesi bile YARA projesinin yetkisinden bahsediyor ve bu:
- VirusTotal Kötü Amaçlı Yazılım İstihbarat Hizmetleri (vt-mis.com);
- jsunpack-n (jsunpack.jeek.org);
- Web Sitenizi İzliyoruz (wewatchyourwebsite.com).
Tüm kod Python'da yazılmıştır ve kullanıcıya hem geliştirmelerinde kullanması için modülün kendisi hem de YARA'yı bağımsız bir uygulama olarak kullanması için basit bir yürütülebilir dosya sunulur. Çalışmamın bir parçası olarak ilk seçeneği seçtim, ancak bu makalede kolaylık olması açısından analizörü bir konsol uygulaması olarak kullanacağız.
Biraz araştırdıktan sonra, YARA için kuralların nasıl yazılacağını ve ücretsiz yazılımdan ve paketleyicilerden virüs imzalarının PEiD'ye nasıl ekleneceğini hızla öğrendim. Ancak kurulumla başlayacağız.
Kurulum
Daha önce de söylediğim gibi proje Python ile yazıldığı için Linux, Windows ve Mac'e kolaylıkla kurulabiliyor. İlk başta ikiliyi alabilirsiniz. Uygulamayı konsolda çağırırsak başlatma kurallarını alırız.
$yara
kullanımı: yara ... ... DOSYA | PID
Yani, programı çağırma formatı şu şekildedir: önce programın adı, ardından bir seçenekler listesi, ardından kuralları içeren dosya belirtilir ve en sonunda - dosyanın adı gösterilir. incelenen (veya dosyaları içeren dizin) veya işlem tanımlayıcı. Şimdi bu kuralların nasıl belirlendiğini güzel bir şekilde açıklamak isterim, ancak sizi hemen kuru teorilerle boğmak istemiyorum. Bu nedenle, YARA'nın belirlediğimiz görevlerden birini - virüslerin imzalarla tam teşekküllü tespiti - gerçekleştirebilmesi için işleri farklı yapacağız ve başkalarının imzalarını ödünç alacağız.
Kendi antivirüsünüz
En önemli soru: Bilinen virüslerin imzalarının bulunduğu veritabanı nereden alınır? Antivirüs şirketleri bu tür veritabanlarını kendi aralarında aktif olarak paylaşıyor (bazıları daha cömert, diğerleri daha az). Dürüst olmak gerekirse, ilk başta internette birinin bu tür şeyleri açıkça yayınlayacağından bile şüpheliydim. Ama ortaya çıktığı gibi, iyi insanlar var. Popüler ClamAV antivirüsünün uygun bir veritabanı herkesin kullanımına açıktır (clamav.net/lang/en). "En Son Kararlı Sürüm" bölümünde şu bağlantıya ulaşabilirsiniz: En son sürüm antivirüs ürününün yanı sıra ClamAV virüs veritabanlarını indirmek için bağlantılar. Öncelikle main.cvd (db.local.clamav.net/main.cvd) ve daily.cvd (db.local.clamav.net/daily.cvd) dosyalarıyla ilgileneceğiz.
Birincisi ana imza veritabanını içerir, ikincisi ise en eksiksiz veritabanını içerir şu ançeşitli eklemelerle temel. 100.000'den fazla kötü amaçlı yazılım gösterimi içeren Daily.cvd bu amaç için oldukça yeterlidir. Ancak ClamAV veritabanı YARA veritabanı olmadığından istediğimiz formata dönüştürmemiz gerekiyor. Ama nasıl? Sonuçta ne ClamAV formatı ne de Yara formatı hakkında henüz bir şey bilmiyoruz. ClamAV virüs imza veritabanını bir dizi YARA kuralına dönüştüren küçük bir komut dosyası hazırlanarak bu sorun bizden önce çözüldü. Betiğin adı clamav_to_yara.py'dir ve Matthew Richard (bit.ly/ij5HVs) tarafından yazılmıştır. Komut dosyasını indirin ve veritabanlarını dönüştürün:
$ python clamav_to_yara.py -f daily.cvd -o clamav.yara
Sonuç olarak clamav.yara dosyasında hemen kullanıma hazır olacak bir imza veritabanı alacağız. Şimdi YARA ve ClamAV veritabanı kombinasyonunu çalışırken deneyelim. İmza kullanarak bir klasörü taramak tek bir komutla gerçekleştirilir:
$ yara -r clamav.yara /pentest/msf3/data
-r seçeneği, taramanın geçerli klasörün tüm alt klasörlerinde yinelemeli olarak gerçekleştirilmesi gerektiğini belirtir. /pentest/msf3/data klasöründe herhangi bir virüs gövdesi varsa (en azından ClamAV veritabanında olanlar), YARA bunu derhal bildirecektir. Prensip olarak bu hazır bir imza tarayıcısıdır. Daha fazla kolaylık sağlamak için ClamAV veritabanı güncellemelerini kontrol eden, yeni imzalar indiren ve bunları YARA formatına dönüştüren basit bir komut dosyası yazdım. Ama bunlar zaten detay. Görevin bir kısmı tamamlandı, artık paketleyicileri/şifreleyicileri tanımlamak için kurallar oluşturmaya başlayabilirsiniz. Ancak bunu yapabilmek için onlarla biraz uğraşmam gerekiyordu.
Kurallara göre oyna
Dolayısıyla kural, belirli bir dosyayı belirli bir kategoriye atamanıza izin veren bir programın ana mekanizmasıdır. Kurallar ayrı bir dosyada (veya dosyalarda) açıklanmıştır ve görünüş olarak C/C++ dilindeki struct() yapısına çok benzemektedir.
BadBoy'u yönet
{
Teller:
$a = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
durum:
$a ve ($b veya $c)
}
Prensip olarak kuralların yazılmasında karmaşık bir şey yoktur. Bu yazıda sadece ana noktalara değindim, detayları kılavuzda bulacaksınız. Şimdilik en önemli on nokta:
1. Her kural, anahtar kelime kuralıyla başlar ve ardından kural tanımlayıcı gelir. Tanımlayıcılar C/C++'daki değişkenlerle aynı adlara sahip olabilir, yani harf ve rakamlardan oluşabilir ve ilk karakter sayı olamaz. Maksimum uzunluk tanımlayıcı adı - 128 karakter.
2. Tipik olarak kurallar iki bölümden oluşur: bir tanım bölümü (dizeler) ve bir koşul bölümü (koşul). Dizeler bölümü, belirli bir dosyanın belirli koşulları karşılayıp karşılamadığına koşul bölümünün karar vereceği temel alınarak verileri belirtir.
3. Dizeler bölümündeki her satırın, genel olarak PHP'deki değişken bildirimi gibi, $ işaretiyle başlayan kendi tanımlayıcısı vardır. YARA, içinde yer alan normal dizeleri destekler ikili alıntı("") ve onaltılık dizeler içine alınmış diş telleri(()) ve normal ifadeler:
$my_text_string = "metin buraya"
$my_hex_string = ( E2 34 A1 C8 23 FB )
4. Koşul bölümü kuralın tüm mantığını içerir. Bu bölüm, bir dosya veya işlemin kuralla ne zaman eşleştiğini belirleyen bir Boolean ifadesi içermelidir. Tipik olarak bu bölüm daha önce bildirilen satırlara atıfta bulunur. Ve dize tanımlayıcısı, dize dosyada veya işlem belleğinde bulunursa true değerini, aksi halde false değerini döndüren bir boole değişkeni olarak değerlendirilir. Yukarıdaki kural, win.exe dizesini ve iki URL'den birini içeren dosya ve işlemlerin BadBoy (kural adına göre) olarak sınıflandırılması gerektiğini belirtir.
5. Onaltılık dizeler, onları daha esnek hale getiren üç yapıya izin verir: joker karakterler, atlamalar ve alternatifler. Değiştirmeler bir dizedeki bilinmeyen ve herhangi bir değerle değiştirilebilen yerlerdir. “?” sembolüyle gösterilirler:
$hex_string = ( E2 34 ?? C8 A? FB )
Bu yaklaşım, uzunluğu bilinen dizeleri belirtirken çok kullanışlıdır ancak içerik değişebilir. Bir dizenin bir kısmı farklı uzunluklarda olabiliyorsa aralıkların kullanılması uygundur:
$hex_string = ( F4 23 62 B4 )
Bu giriş, satırın ortasında 4 ila 6 farklı bayt olabileceği anlamına gelir. Alternatif bir seçeneği de uygulayabilirsiniz:
$hex_string = ( F4 23 (62 B4 | 56) 45 )
Bu, üçüncü bayt yerine 62 B4 veya 56 olabileceği anlamına gelir; böyle bir giriş, F42362B445 veya F4235645 satırlarına karşılık gelir.
6. Belirli bir dizenin bir dosya veya işlem adres alanında belirli bir konumda olup olmadığını kontrol etmek için at operatörü kullanılır:
100'de $a ve 200'de $b
Dize belirli bir adres aralığında olabiliyorsa in operatörü kullanılır:
$a inç (0..100) ve $b inç (100..fi lesize)
Bazen bir dosyanın belirli bir kümeden belirli bir sayı içermesi gerektiğini belirtmeniz gerektiğinde durumlar ortaya çıkar. Bu of operatörü kullanılarak yapılır:
Örnek1 kuralı
{
Teller:
$foo1 = "kukla1"
$foo2 = "kukla2"
$foo3 = "kukla3"
durum:
2 / ($foo1,$foo2,$foo3)
}
Yukarıdaki kural, dosyanın kümeden herhangi iki satırı içermesini gerektirir ($foo1,$foo2,$foo3). Dosyada belirli sayıda satır belirtmek yerine, herhangi biri (belirli bir kümedeki en az bir satır) ve tümü (belirli bir kümedeki tüm satırlar) değişkenlerini kullanabilirsiniz.
7. Dikkate alınması gereken son ilginç olasılık, bir koşulun birçok satıra uygulanmasıdır. Bu özellik of operatörüne çok benzer, ancak for..of operatörü daha güçlüdür:
string_set'in ifadesi için: (boolean_expression)
Bu giriş şu şekilde okunmalıdır: string_ setinde belirtilen dizelerden en azından ifade parçalarının boolean_expression koşulunu karşılaması gerekir. Veya başka bir deyişle: boolean_expression, dize_kümesi içindeki her dize için değerlendirilir ve bunlardan gelen ifadelerin True döndürmesi gerekir. Daha sonra bu yapıya belirli bir örnek kullanarak bakacağız.
PEiD yapma
Böylece, kurallarla ilgili her şey az çok netleştiğinde, projemizde paketleyiciler ve kriptolayıcılardan oluşan bir dedektör uygulamaya başlayabiliriz. İlk başta kaynak materyal olarak aynı PEiD'den tanınmış paketleyicilerin imzalarını ödünç aldım. Eklentiler klasöründe ihtiyacımız olanı içeren userdb.txt dosyası var. Veritabanımda 1850 imza vardı.
Oldukça fazla, bu yüzden bunları tamamen içe aktarmak için bir tür senaryo yazmanızı tavsiye ederim. Bu veritabanının formatı basittir; olağan format kullanılır Metin dosyası, aşağıdaki gibi kayıtları saklar:
imza = 50 E8 ?? ?? ?? ?? 58 25 ?? F0 FF FF 8B C8 83 C1 60 51 83 C0 40 83 EA 06 52 FF 20 9D C3
ep_only = doğru
İlk satır, PEiD'de görüntülenecek olan paketleyicinin adını belirtir, ancak bizim için kural tanımlayıcı olacaktır. İkincisi imzanın kendisidir. Üçüncüsü, belirli bir satırın yalnızca giriş noktası adresinde mi yoksa dosyanın tamamında mı aranacağını belirten ep_only bayrağıdır.
Peki, diyelim ki ASPack için bir kural oluşturmaya çalışalım mı? Görünüşe göre bu konuda karmaşık bir şey yok. Öncelikle kuralları saklayacak bir dosya oluşturalım ve onu örneğin packers.yara olarak adlandıralım. Daha sonra isimlerinde ASPack geçen tüm imzaları PEiD veritabanında araştırıp kurala aktarıyoruz:
kural ASPack
{
Teller:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ?? ?? (43 | 44) ?? 03 C5 )
$ = ( 60 EB ?? 5D EB ?? FF ?? ?? ?? ?? ?? E9 )
[.. kesmek..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
durum:
bunlardan herhangi biri için: (giriş noktasında $)
}
Bulunan tüm kayıtlarda ep_only bayrağı true olarak ayarlanmıştır, yani bu satırların giriş noktası adresinde bulunması gerekir. Bu nedenle şu koşulu yazıyoruz: “bunlardan herhangi biri için: (giriş noktasında $)”.
Dolayısıyla giriş noktası adresinde verilen satırlardan en az birinin bulunması dosyanın ASPack ile paketlendiği anlamına gelecektir. Ayrıca bu kuralda tüm satırların bir tanımlayıcı olmadan yalnızca $ işareti kullanılarak belirtildiğini lütfen unutmayın. Bu mümkündür çünkü koşul bölümünde belirli olanlara erişmeyiz, ancak setin tamamını kullanırız.
Ortaya çıkan sistemin işlevselliğini kontrol etmek için konsolda komutu çalıştırmanız yeterlidir:
$ yara -r packers.yara somefi le.exe
Orada ASPack ile paketlenmiş birkaç uygulamayı besledikten sonra her şeyin işe yaradığına ikna oldum!
Hazır prototip
YARA'nın son derece açık ve şeffaf bir araç olduğu ortaya çıktı. Bunun için bir webadmin yazıp onu bir web servisi olarak çalışacak şekilde ayarlamak benim için zor olmadı. Biraz yaratıcılıkla, analizörün kuru sonuçları zaten farklı renklerde renklendirilir ve bu da tespit edilen kötü amaçlı yazılımın tehlike derecesini gösterir. Veritabanında küçük bir güncelleme ve çoğu kriptolayıcı için kısa bir açıklama ve hatta bazen paketten çıkarma talimatları mevcuttur. Prototip oluşturuldu ve mükemmel çalışıyor ve patronlar keyifle dans ediyor!
Telgraf başlığındaki fonksiyon kodu (FC), Talep telgrafı (İstek veya Gönder/Talep) ve Onay veya Yanıt telgrafı (Onay çerçevesi, Yanıt çerçevesi) gibi telgraf türünü tanımlar. Ek olarak fonksiyon kodu, mesajların kaybolmasını ve çoğaltılmasını önleyen gerçek iletim fonksiyonunu ve kontrol bilgilerini veya FDL statüsündeki istasyon tipini içerir.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: İşlev Kodu İsteği |
| 1 | Telgraf Talebi | |||||||
| X | FCV = Alternatif bit açık | |||||||
| X | href=”http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit”>FCB = Alternatif bit (kare sayısından) | |||||||
| 1 | 0 (0x0) | CV = Saat Değeri() | ||||||
| 1 | diğer | Rezerve | ||||||
| 0 | 0 (0x0) | TE = Zaman Olayı (Saat senkronizasyonu) | ||||||
| 0 | 3 (0x3) | SDA_LOW = Veri Gönderme Onaylandı - düşük öncelik | ||||||
| 0 | 4 (0x4) | SDN_LOW = Veri Gönder Onaylanmadı - düşük öncelik | ||||||
| 0 | 5 (0x5) | SDA_HIGH = Veri Gönderimi Onaylandı - yüksek öncelik | ||||||
| 0 | 6 (0x6) | SDN_HIGH = Veri Gönder Onaylanmadı | ||||||
| 0 | 7 (0x7) | MSRD = Çok Noktaya Yayın Yanıtı ile İstek Verilerini Gönder | ||||||
| 0 | 9 (0x9) | FDL Durumunu İste | ||||||
| 0 | 12(0xC) | SRD düşük = Veri Gönder ve İste | ||||||
| 0 | 13(0xD) | SRD yüksek = Veri Gönder ve İste | ||||||
| 0 | 14(0xE) | Yanıtla Kimlik İste | ||||||
| 0 | 15 (0xF) | Yanıtla LSAP Durumunu Talep Et 1) | ||||||
| 0 | diğer | Rezerve | ||||||
1) bu değer standardın son versiyonundadır, artık tanımlanmamıştır ancak yalnızca ayrılmıştır
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: İşlev Kodu Yanıtı |
| 0 | Yanıt telgrafı | |||||||
| 0 | Rezerve | |||||||
| 0 | 0 | Köle | ||||||
| 0 | 1 | Usta hazır değil | ||||||
| 1 | 0 | Master hazır, belirteç olmadan | ||||||
| 1 | 1 | Master hazır, token ringde | ||||||
| 0 (0x0) | TAMAM | |||||||
| 1 (0x1) | UE = Kullanıcı Hatası | |||||||
| 2 (0x2) | RR = Kaynak yok | |||||||
| 3 (0x3) | RS = SAP etkin değil | |||||||
| 8 (0x8) | DL = Düşük Veri (DP'de normal durum) | |||||||
| 9 (0x9) | NR = Yanıt verisi hazır değil | |||||||
| 10(0xA) | DH = Yüksek Veri (DP tanısı bekleniyor) | |||||||
| 12(0xC) | RDL = Veri alınmadı ve Veri Düşük | |||||||
| 13(0xD) | RDH = Veri alınmadı ve Veri Yüksek | |||||||
| diğer | Rezerve | |||||||
Çerçeve Sayısı Biti Çerçeve sayımı biti FCB (b5), onaylayan veya yanıt veren istasyon (yanıtlayıcı) tarafından mesajın çoğaltılmasını ve çağrı istasyonunun (başlatıcı) herhangi bir kaybını önler. Onaysız istekler (SDN) ve FDL Durumu, Kimlik ve LSAP Durumu istekleri bunun dışındadır.
Güvenlik dizisi için, başlatıcının her müdahaleci için bir FCB taşıması gerekir. Bir Talep telgrafı (Talep veya Gönder/Talep) bir yanıtlayıcıya ilk kez gönderildiğinde veya halihazırda çalışmıyor olarak işaretlenmiş bir yanıtlayıcıya yeniden gönderilirse, FCB'nin yanıtlayıcıda tanımlandığı gibi ayarlanması gerekir. Başlatıcı bunu FCV=0 ve FCB=1 olan bir İstek telgrafında gerçekleştirir. Yanıtlayan kişi bu tür bir telgrafı ilk mesaj döngüsü olarak değerlendirmeli ve FCB=1'i başlatanın adresiyle (SA) birlikte kaydetmelidir (aşağıdaki tabloya bakınız). Bu mesaj döngüsü başlatıcı tarafından tekrarlanmayacaktır. Aynı yanıtlayıcıya gönderilen sonraki Talep telgraflarında, başlatıcı FCV=1 ayarlamalı ve her yeni Talep telgrafıyla FCB'yi değiştirmelidir. Kendisine FCV=1 ile gönderilen bir İstek telgrafı alan herhangi bir yanıtlayıcı, FCB'yi değerlendirmelidir. FCB, aynı başlatıcıdan (aynı SA) gelen son İstek telgrafıyla karşılaştırıldığında değiştiyse, bu, önceki mesaj döngüsünün düzgün bir şekilde sonlandırıldığına dair geçerli bir onaydır. Talep telgrafı farklı bir başlatıcıdan (farklı SA) geliyorsa FCB'nin değerlendirilmesine artık gerek yoktur. Her iki durumda da yanıtlayan kişi, kendisine gönderilen yeni bir telgraf alınana kadar FCB'yi kaynak SA ile birlikte kaydetmelidir. Onay veya yanıt telgrafının kaybolması veya bozulması durumunda, FCB, talep yeniden denemesinde başlatıcı tarafından değiştirilmemelidir: bu, önceki mesaj döngüsünün hatalı olduğunu gösterecektir. Yanıt veren, aynı başlatıcıdan (aynı SA) FCV=1 ve son İstek telgrafıyla aynı FCB'ye sahip bir Talep telgrafı alırsa, bu, talebin yeniden denendiğini gösterecektir. Yanıtlayan kişi, hazır tutulan onay veya yanıt telgrafını yeniden iletmelidir. Yukarıda belirtilen, farklı bir adrese (SA veya DA) sahip ve onaylanmayan bir telgrafın (Onaysız Veri Gönderme, SDN) onayına veya alınmasına kadar, yanıtlayan kişi, olası herhangi bir yeniden istek denemesi için son alındı bildirimini veya yanıt telgrafını hazır bulundurmalıdır. . Onaylanmayan ve Talep FDL Durumu, Kimlik ve LSAP Durumu olan Talep telgrafları durumunda, FCV=0 ve FCB=0; Yanıt verenin değerlendirmesi artık gerekli değildir.
| b5 | b4 | Bit konumu | ||
| FCB | FCV | Durum | Anlam | Aksiyon |
| 0 | 0 | DA = TS/127 | Onaylanmadan istek FDL Durumu/Kimlik/LSAP Durumu Talebi |
Son onayı sil |
| 0/1 | 0/1 | DA#TS | Başka bir yanıtlayıcıya istek | |
| 1 | 0 | DA = TS | İlk istek | FCBM:= 1 SAM:=SA Son onayı/yanıtı sil |
| 0/1 | 1 | DA = TS SA = SAM FCB#FCBM |
Yeni istek | Son onayı/yanıtı sil FCBM:=FCB Onaylamayı/yanıtı yeniden denemeye hazır tutun |
| 0/1 | 1 | DA = TS SA = SAM FCB = FCBM |
Yeniden Deneme İsteği | FCBM:=FCB Onaylamayı / yanıtı tekrarlayın ve hazırlıklı olmaya devam edin |
| 0/1 | 1 | DA = TS SA#SAM |
Yeni başlatıcı | FCBM:=FCB SAM:= SA Yeniden denemeye hazır durumda onayı / yanıtı beklet |
FCBM, FCB'yi bellekte sakladı SAM, SA'yı bellekte sakladı
