病毒靜態分析技術
原理
程式靜態分析(Program Static Analysis)是指在不執行程式碼的方式下,通過詞法分析、語法分析、控制流、資料流分析等技術對程式程式碼進行掃描,驗證程式碼是否滿足規範性、安全性、可靠性、可維護性等指標的一種程式碼分析技術。可利用該技術來驗證軟體是否為病毒,一般重以下幾個方面進行分析:
字串查殺
在程式未執行的情況下,使用一些工具,提取程式字串,檢視是否有可疑資訊,來判斷是否為病毒,原理與解析如下:
- 定義:字串或串(String)是由數字、字母、下劃線組成的一串字元,主要用於程式設計,概念說明、函式解釋等,補充知識:字串在儲存上類似字元陣列,所以它每一位的單個元素都是可以提取的
- 常用於:輸出資訊、URL地址、檔名稱、路徑資訊等等。
- 因計算機只能識別0和1兩種數字,為了使用輸入指定的字串,常使用編碼技術來解決這一問題
- 定義:編碼是資訊從一種形式或格式轉換為另一種形式的過程也稱為計算機程式語言的程式碼簡稱編碼。用預先規定的方法將文字、數字或其它物件編成數碼,或將資訊、資料轉換成規定的電脈衝訊號。編碼在電子計算機、電視、遙控和通訊等方面廣泛使用。編碼是資訊從一種形式或格式轉換為另一種形式的過程。解碼,是編碼的逆過程。
- 常見編碼技術
- ASCII編碼:是基於拉丁字母的一套電腦編碼系統,主要用於顯示現代英語和其他西歐語言。
- Unicode編碼:是電腦科學領域裡的一項業界標準,包括字符集、編碼方案等。Unicode是為了解決傳統的字元編碼方案的侷限而產生的,它為每種語言中的每個字元設定了統一併且唯一的二進位制編碼,以滿足跨語言、跨平臺進行文字轉換、處理的要求。
- GB 2312編碼:適用於漢字處理、漢字通訊等系統之間的資訊交換,通行於中國大陸;新加坡等地也採用此編碼。中國大陸幾乎所有的中文系統和國際化的軟體都支援GB 2312。
- GBK編碼:GBK編碼標準相容GB2312,共收錄漢字21003個、符號883個,並提供1894個造字碼位,簡、繁體字融於一庫。
- 如何從計算機的二進位制編碼中,提取出字串,可以使用以下工具
- Strings
- 官網:https://docs.microsoft.com/zh-cn/sysinternals/downloads/strings
- 功能:在物件檔案或二進位制檔案中查詢可列印的字串
- 缺陷:但是它將忽略上下文格式。搜尋出的可能是:記憶體地址、CPU指令序列、一段資料等等
- 限制:它只搜尋三個或以上連續的ASCII(2個0結尾)或Unicode(4個0結尾)字元,並以終結符結尾的可列印字串。
- 針對:計算機病毒可利用該搜尋限制,導致Strings搜尋不到有用字串(例如:將所有字元變成兩個字元,在進行拼接)
- 技巧:搜尋時修改檔案字尾名,避免執行
- SDL Passolo
- 官網:https://www.sdltrados.cn/cn/products/passolo/
- 功能:軟體本地化工具,當然也可以搜尋字串
- 缺陷:程式體積大
- Resource Hacker
- Lingobit Localizer
- Resource Tuner
- Restorator
- Sisulizer
- 官網:https://www.sisulizer.com/
一般搜尋到url或其它IP地址就要小心了,很有可能就是病毒,做好防護再訪問驗證,避免網頁掛馬。
- 官網:https://www.sisulizer.com/
PE查殺
由於大多數感染型病毒都是感染的PE檔案,因為這樣才可以在PE檔案執行的同時執行自身的病毒程式碼。從而繼續感染其他的正常檔案,以達到傳播的自身的目的。所以從防毒角度講,應該先判斷一個檔案是否為PE結構,再去進一步決定應該使用何種方法對檔案進行掃描處理。那麼,如何判斷一個檔案是否為PE結構呢,先從pe的概念開始入手:
- PE概念:PE( Portable Execute)檔案是Windows下可執行檔案的總稱,常見的有 DLL,EXE,OCX,SYS 等
- 適用範圍:Windows可執行程式和動態連結庫
- 包含資訊:Windows如何將檔案從硬碟裝載到記憶體中執行所需的必要資訊
事實上,一個檔案是否是 PE 檔案與其副檔名無關,PE檔案可以是任何副檔名。那 Windows 是怎麼區分可執行檔案和非可執行檔案的呢?我們呼叫 LoadLibrary 傳遞了一個檔名,系統是如何判斷這個檔案是一個合法的動態庫呢?這就涉及到PE檔案結構了。 - PE結構
- DOS頭:
DOS頭中宣告用的暫存器(可以看到e_ss、e_sp、e_ip、e_cs還是16位的暫存器),所以在32位/64為系統中用到的只有兩個:- e_magic:判斷一個檔案是不是PE檔案,使用MZ標記;//(WORD 2位元組變數)
- e_lfanew:相對於檔案首的偏移量,用於找到PE頭;//(DWORD 4位元組變數)
- struct _IMAGE_DOS_HEADER
- typedef struct _IMAGE_DOS_HEADER {
WORD e_magic; //※Magic DOS signature MZ(4Dh 5Ah):MZ標記:用於標記是否是可執行檔案
WORD e_cblp; //檔案最後一頁的位元組數
WORD e_cp; //檔案中的頁面
WORD e_crlc; //重新安置
WORD e_cparhdr; //段落標題大小
WORD e_minalloc; //最少的額外段落需求
WORD e_maxalloc; //最大的額外段落需求
WORD e_ss; //初始(相對)SS值
WORD e_sp; //初始SP值
WORD e_csum; //校驗和
WORD e_ip; //初始IP值
WORD e_cs; //初始(相對)CSS值
WORD e_lfarlc; //重定位表的檔案地址
WORD e_ovno; //疊加數
WORD e_res[4]; //保留字
WORD e_oemid; //OEM識別符號(用於e_oeminfo)
WORD e_oeminfo; //OEM資訊;特定於e_oemid
WORD e_res2[10]; //保留字
DWORD e_lfanew; //※Offset to start of PE header:定位PE檔案,PE頭相對於檔案的偏移量
}IMAGE_DOS_HEADER, * PIMAGE_DOS_HEADER;
- PE檔案頭:
PE頭分為標準PE頭和可選PE頭,其同為NT結構的成員記錄可執行程式碼資訊
包含:程式的型別,exe可執行程式、dll動態連結庫程式
作用:Windows基於PE檔案頭來將可執行程式和所依賴的動態連結庫對映到記憶體中 - 標準PE頭:
struct IMAGE_FILE_HEADER
typedef struct _IMAGE_FILE_HEADER
{
WORD Machine; //※程式執行的CPU平臺:0X0:任何平臺,0X14C:intel i386及後續處理器
WORD NumberOfSections; //※PE檔案中區塊數量
ULONG TimeDateStamp; //時間戳:聯結器產生此檔案的時間距1969/12/31-16:00P:00的總秒數
ULONG PointerToSymbolTable;//COFF符號表格的偏移位置。此欄位只對COFF除錯資訊有用
ULONG NumberOfSymbols; //COFF符號表格中的符號個數。該值和上一個值在release版本的程式裡為0
WORD SizeOfOptionalHeader;//IMAGE_OPTIONAL_HEADER結構的大小(位元組數):32位預設E0H,64位預設F0H(可修改)
WORD Characteristics; //※描述檔案屬性(單屬性(只有1bit為1):#define IMAGE_FILE_DLL 0x2000 //File is a DLL;組合屬性(多個bit為1,單屬性或運算):0X010F 可執行檔案)
} IMAGE_FILE_HEADER; //*PIMAGE_FILE_HEADER; - 可選PE頭:
struct IMAGE_OPTIONAL_HEADER
typedef struct _IMAGE_OPTIONAL_HEADER
{
WORD Magic; //※ 說明檔案型別:10B 32位、20B 64位
UCHAR MajorLinkerVersion; //連結程式的主版本號
UCHAR MinorLinkerVersion; //連結程式的副版本號
ULONG SizeOfCode; //所有程式碼段的總和大小,注意:必須是FileAlignment的整數倍
ULONG SizeOfInitializedData; //已經初始化資料的大小,注意:必須是FileAlignment的整數倍
ULONG SizeOfUninitializedData; //未經初始化資料的大小,注意:必須是FileAlignment的整數倍
ULONG AddressOfEntryPoint; //※程式入口地址OEP,這是一個RVA(Relative Virtual Address),通常會落在.textsection,此欄位對於DLLs/EXEs都適用。
ULONG BaseOfCode; //程式碼段起始地址(程式碼基址),(程式碼的開始和程式無必然聯絡)
ULONG BaseOfData; //資料段起始地址(資料基址)
ULONG ImageBase; //※記憶體映象基址(預設裝入起始地址),預設為4000H
ULONG SectionAlignment; //※記憶體中的區塊的對齊大小:一旦映像到記憶體中,每一個section保證從一個「此值之倍數」的虛擬地址開始
ULONG FileAlignment; //※檔案中的區塊的對齊大小:最初是200H,現在是1000H
WORD MajorOperatingSystemVersion; //所需作業系統主版本號
WORD MinorOperatingSystemVersion; //所需作業系統副版本號
WORD MajorImageVersion; //自定義主版本號,使用聯結器的引數設定,eg:LINK /VERSION:2.0 myobj.obj
WORD MinorImageVersion; //自定義副版本號,使用聯結器的引數設定
WORD MajorSubsystemVersion; //所需子系統主版本號,典型數值4.0(Windows 4.0/即Windows 95)
WORD MinorSubsystemVersion; //所需子系統副版本號
ULONG Win32VersionValue; //※莫須有欄位,不被病毒利用的話一般為0
ULONG SizeOfImage; //※PE檔案在記憶體中映像總大小,sizeof(ImageBuffer),SectionAlignment的倍數
ULONG SizeOfHeaders; //※DOS頭(64B)+PE標記(4B)+標準PE頭(20B)+可選PE頭+節表的總大小,按照檔案對齊(FileAlignment的倍數)
ULONG CheckSum; //※PE檔案CRC校驗和,判斷檔案是否被修改
WORD Subsystem; //使用者介面使用的子系統型別
WORD DllCharacteristics; //DllMain()函式何時被呼叫,預設為 0
ULONG SizeOfStackReserve; //預設執行緒初始化執行緒棧的保留大小
ULONG SizeOfStackCommit; //初始化時實際提交的執行緒棧大小
ULONG SizeOfHeapReserve; //預設保留給初始化的執行緒棧的虛擬記憶體大小
ULONG SizeOfHeapCommit; //初始化時實際提交的堆大小
ULONG LoaderFlags; //與除錯有關,預設為 0
ULONG NumberOfRvaAndSizes; //目錄項數目:總為0X00000010H(16),這個欄位自Windows NT 釋出以來一直是16
IMAGE_DATA_DIRECTORY DataDirectory[16]; //定義IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER; - PE節表:
PE檔案中所有節的屬性都被定義在節表中,節表由一系列的IMAGE_SECTION_HEADER結構排列而成,每個結構用來描述一個節,結構的排列順序和它們描述的節在檔案中的排列順序是一致的。全部有效結構的最後以一個空的IMAGE_SECTION_HEADER結構作為結束,所以節表中總的IMAGE_SECTION_HEADER結構數量等於節的數量加一。節表總是被存放在緊接在PE檔案頭的地方。
另外,節表中 IMAGE_SECTION_HEADER 結構的總數總是由PE檔案頭 IMAGE_NT_HEADERS 結構中的 FileHeader.NumberOfSections 欄位來指定的。
struct IMAGE_SECTION_HEADER
typedef struct _IMAGE_SECTION_HEADER
{
BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; //區塊名。這是一個由8位的ASCII 碼名,用來定義區塊的名稱。多數區塊名都習慣性以一個“.”作為開頭(例如:.text),這個“.” 實際上是不是必須的。值得我們注意的是,如果區塊名超過 8 個位元組,則沒有最後的終止標誌“NULL” 位元組。並且前邊帶有一個“$” 的區塊名字會從聯結器那裡得到特殊的待遇,前邊帶有“$” 的相同名字的區塊在載入時候將會被合併,在合併之後的區塊中,他們是按照“$” 後邊的字元的字母順序進行合併的。
另外每個區塊的名稱都是唯一的,不能有同名的兩個區塊。但事實上節的名稱不代表任何含義,他的存在僅僅是為了正規統一程式設計的時候方便程式設計師檢視方便而設定的一個標記而已。所以將包含程式碼的區塊命名為“.Data” 或者說將包含資料的區塊命名為“.Code” 都是合法的。當我們要從PE 檔案中讀取需要的區塊時候,不能以區塊的名稱作為定位的標準和依據,正確的方法是按照 IMAGE_OPTIONAL_HEADER32 結構中的資料目錄欄位結合進行定位。
union {
DWORD PhysicalAddress; //實體地址
DWORD VirtualSize; //該區塊表對應的區塊的大小,這是區塊的資料在沒有進行對齊處理前的實際大小。
} Misc;
DWORD VirtualAddress; //該區塊裝載到記憶體中的RVA 地址。這個地址是按照記憶體頁來對齊的,因此它的數值總是 SectionAlignment 的值的整數倍。在Microsoft 工具中,第一個快的預設 RVA 總為1000h。在OBJ 中,該欄位沒有意義地,並被設為0
DWORD SizeOfRawData; //該區塊在磁碟中所佔的大小。在可執行檔案中,該欄位是已經被FileAlignment 處理過的長度
DWORD PointerToRawData; //該區塊在磁碟中的偏移。這個數值是從檔案頭開始算起的偏移量
DWORD PointerToRelocations; //在EXE檔案中沒有意義,在OBJ 檔案中,表示本區塊重定位資訊的偏移值
DWORD PointerToLinenumbers; //行號表在檔案中的偏移值,檔案的除錯資訊
WORD NumberOfRelocations; //在EXE檔案中也沒有意義,在OBJ 檔案中,是本區塊在重定位表中的重定位數目
WORD NumberOfLinenumbers; //該區塊在行號表中的行號數目
DWORD Characteristics; //該區塊的屬性。該欄位是按位來指出區塊的屬性(如程式碼/資料/可讀/可寫等)的標誌
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER; - PE節:
每個節實際上是一個容器,可以包含 程式碼、資料 等等,每個節可以有獨立的記憶體許可權,比如程式碼節預設有讀/執行許可權,節的名字和數量可以自己定義 - 常見的節:
.text:包含了CPU的執行指令、所有其它分節儲存資料、支援性的資訊。一般來說,它是唯一可以執行的分節,也是唯一包含程式碼的節,其中的資料是可讀、可執行的,並且利用CPU指令動態生成技術,可讓資料具有可讀、可寫、可執行功能。
.rdata:包含的資料只具有隻讀功能,通常用來包含匯入匯出函式資訊,還可以儲存程式所使用的其它只讀資料,比如匯入的動態連結庫、匯入的函式資訊等。
.date:程式所用的全域性變數資訊儲存在這裡,它的資料是可讀、可寫的。
.rsrc:該位元組包含由可執行檔案所使用的資源資訊,但這些內容並不能執行的,比如圖示、圖片、選單項和字串,也可以用來儲存其它程式,危害的是也可被用來儲存病毒,在程式執行的時候將這些病毒載入到記憶體當中
- DOS頭:
- 常用的PE分析工具
- PEview(roguekillerpe):https://www.adlice.com/download/roguekillerpe/
- StudyPE:https://www.chinapyg.com/forum.php?mod=viewthread&tid=137051&highlight=study%2Bpe
- PPEE:https://mzrst.com/
- CFF Explorer:https://ntcore.com/?page_id=388
- PE Explorer:http://www.heaventools.com/overview.htm
查殺技巧:
### 判斷PE檔案中程式入口點是否異常
很多病毒在感染了PE檔案後,通常都會向PE檔案中新增一部分程式碼, 然後更改P E 頭中的AddressOfEntryPoint,將他指向的地址定位到病毒插入的程式碼處,這樣每當這個檔案執行時,病毒程式碼都會最先得到執行。
一般情況,很多病毒都將插入到PE檔案中的程式碼放到PE檔案的後面,然後在程式碼尾部放置一條語句再跳回到原來PE檔案真正入口點處。使得使用者在毫無察覺的情況下執行病毒程式碼。防毒軟體可以根據PE檔案入口點是否異常來判斷檔案是否有被病毒感染的嫌疑。通常入口點所指的相對虛擬地址比較靠前,不會在靠近檔案末尾處,或者指向最後一個節後的內容,如果一個PE檔案的入口點的指向不是這樣,那麼就說明這個檔案有被病毒感染的嫌疑。當然,這種主觀的判斷不一定準確,但是可以算是一種判斷的依據。上期我們提到的啟發式掃描就會用到這樣的特徵來幫助判斷未知病毒。
有些病毒為了防止反病毒軟體的這種探測,也想出了很多不修改入口點改變程式流程的方法。例如,改變原入口點程式的程式碼,再跳轉到病毒體。
### 根據PE結構取特徵碼
特徵碼的提取是將檔案劃分為不同的部分,然後從每部分中提取一定長度的內容作為特徵碼。這樣提取特徵碼的方法存在著一個問題就是很多病毒的特徵碼有類似的部分,例如我們討論的PE結構,很多PE檔案開頭部分有很大一部分是相同的,所以按照等分劃分檔案的方法來提取特徵碼是不理想的。這時我們考慮到了利用PE結構,從每個節中提取一定的內容作為特徵碼,或者以各種關鍵點為參照,在附近找特徵碼。這樣一來,可以大大避免了上面所提到的等分劃分檔案提取特徵碼方法的弊端,增強了不同病毒間特徵碼的差異性。例如本次對於CIH 病毒的檢測,就檢查了PE Header 附近和入口點附近的特徵。
#### CIH病毒的識別
取3 個特徵:
首先是在PE Header前一個位元組如果非0,就有可能感染了,CIH 自己也利用了這個來判斷。
但是這個特徵是不一定可靠的,沒有感染CIH病毒的程式這個地方也可能因為各種原因變成非0,所以還加了兩條程式碼特徵。
CIH會改變程式碼入口,指向自己,根據這個,我們取了入口點偏移特徵,將sidt動作和後面掛檔案系統鉤子兩個動作作為了特徵,這樣就比較可靠了。
當然,這3個特徵都集中在病毒頭部,如果要更可靠,避免家族內的誤報,還可以增加一些病毒體後面的程式碼。
連結庫與函式
在計算機病毒分析中連結庫與函式可以給病毒分析帶來很多有用的資訊,那它們又是如何被計算機病毒盯上的呢?懷著這個疑問,進行進一步的學習:
盯上原因:病毒利用PE結構中的匯入表將計算機病毒需要的連結庫、函式等含有惡意內容的東西匯入到計算機記憶體裡面,並呼叫動態連結庫中的函式(通過連結庫將計算機病毒程式碼與動態連結庫連線在一起)進行準備工作
* 引入問題:連結是什麼都有什麼連結方法
連結所解決的問題即是將我們自己寫的程式碼和別人寫的庫整合在一起。
* 靜態連結:是Windows平臺連結程式碼庫最不常用的方法,但在UNIX和Linux程式中是比較常見的。
特點:在生成可執行檔案的時候(連結時間),把所有需要的函式的二進位制程式碼都包含到可執行檔案中去。因此,連結器需要知道參與連結的目標檔案需要哪些函式,同時也要知道每個目標檔案都能提供什麼函式,這樣連結器才能知道是不是每個目標檔案所需要的函式都能正確地連結。
如果某個目標檔案需要的函式在參與連結的目標檔案中找不到的話,連結器就報錯了。
目標檔案中有兩個重要的介面來提供這些資訊:一個是符號表,另外一個是重定位表。
當一個庫被靜態連結到可執行程式時,所有這個庫中的程式碼都會複製到可執行程式中去。
優點:在程式釋出的時候就不需要的依賴庫,也就是不再需要帶著庫一塊釋出,程式可以獨立執行。
缺點:但在PE檔案頭中沒有連結庫的資訊,這種方法會導致可執行程式體積變大,佔用更多的記憶體空間;如果靜態庫有更新的話,所有可執行檔案都得重新連結才能用上新的靜態庫。通常計算機病毒為減小病毒體積一般不使用這種連結方法。
連結時間:在生成可執行檔案的時候(編譯過程中進行的連結)
* 動態連結:動態連結時最常見的,對於惡意程式碼分析師也應該時最關注的,動態連結資訊寫在匯入表中,當代碼庫被動態連結時,宿主作業系統會在程式被裝載時搜尋所需要的程式碼庫,如果程式呼叫了被連結的庫函式,這個函式會在程式碼庫中執行
特點:在編譯的時候不直接拷貝可執行程式碼,而是通過記錄一系列符號和引數,在程式執行或載入時將這些資訊傳遞給作業系統,作業系統負責將需要的動態庫載入到記憶體中,然後程式在執行到指定的程式碼時,去共享執行記憶體中已經載入的動態庫可執行程式碼,最終達到執行時連線的目的。
優點:多個程式可以共享同一段程式碼,而不需要在磁碟上儲存多個拷貝。
缺點:由於是執行時載入,可能會影響程式的前期執行效能。
連結時間:在程式執行或載入時
執行時連結:當應用程式呼叫LoadLibrary 或 LoadLibraryEx 函式時,系統就會嘗試按載入時動態連結搜尋次序(參見載入時動態連結)定位DLL。如果找到,系統就把DLL模組對映到程序的虛地址空間中,並增加引用計數。如果呼叫LoadLibrary或LoadLibraryEx 時指定的DLL其程式碼已經對映到呼叫程序的虛地址空間,函式就會僅返回DLL的控制代碼並增加DLL引用計數。注意:兩個具有相同檔名及副檔名但不在同一目錄的DLL被認為不是同一個DLL。
* 備註:雖然執行時連結在合法程式中並不流行,但是惡意程式碼中是常用的,特別是當惡意程式碼被加殼或混淆的時候。因為加殼或混淆會破壞計算機病毒的匯入表,沒有匯入表Windows系統不會幫助病毒完成連結工作,所以需要在執行的時候利用執行時連結這種方法,將所需要的連結庫和函式裝載到記憶體空間中。
特點:需要的適合才進行連結
優點:使用執行時連結的可執行程式,只有當需要使用函式時,才連結到庫,而並不是像動態連結模式一樣在程式啟動時就會連結
缺點:需要使用相關函式才可以呼叫
連結時間:遇到呼叫函式時
基於連結的分析:
PE檔案頭列出了計算機病毒程式碼所需的所有動態連結庫和函式
動態連結庫和函式名字可以用來分析計算機病毒的功能
常用的動態連結庫的資訊:
常用的分析工具:
Dependency Walker:包含在Visual Studio的一些版本與其它微軟開發包中,支援列出可執行檔案的動態連結函式
病毒中常見的函式:
LoadLibrary:將動態連結庫動態的從硬碟裝載到計算機病毒的記憶體空間
GetProcAddress:在動態連結庫中找到對應函式的地址
URLDownloadToFile():會從Internet上下載一個檔案
* 匯入函式
PE檔案頭中也包含了可執行檔案使用的特定函式相關資訊,因為在匯入函式只能看到這個函式的名字,為了瞭解函式的引數資訊、功能資訊以及使用方法,可以在微軟的MSDN中找到這些資訊,當然了使用搜索引擎也是可以的。
* 匯出函式
與匯入函式類似,DLL和EXE的匯出函式,是用來與其它程式和程式碼進行互動時所使用的。
通常,一個DLL會實現一個或多個功能函式,然後將它們匯出,是的別的程式可以匯入並使用這些函式。
PE檔案中也包含了一個檔案中匯出了哪些函式資訊
輔助查殺
常用防毒軟體、惡意軟體查殺平臺、惡意軟體分析平臺等進行輔助查殺,它們具有如下優勢:
* 擁有病毒特徵庫:一個數據庫,它裡面記錄著已知病毒的種種“相貌特徵”,根據這些專屬特徵,可鑑定軟體是否為病毒,主要針對已知病毒。
* 病毒針對:計算機病毒的編寫者可以很容易的修改自己的程式碼,從而改變這些病毒的各種特徵,常通過如下技術來躲避防毒軟體的檢測
* 多型技術:語義不變,語法混淆,增加逆向分析難度。
* 變形技術:功能不變,語義混淆,增加逆向分析難度。
* 單向執行技術:未解密數字猜想、雜湊值,增加逆向分析難度。
* 垃圾指令:使用大量對分析時無用的指令,增加逆向分析難度。
* 擁有啟發式規則:因有的病毒特徵在特徵庫沒有,防毒軟體未查殺這些未知病毒,就根據已知的病毒分析經驗總結出一些規則,來鑑定軟體是否為病毒,主要針對未知病毒。
* 病毒針對:開發新型病毒,不使用也被防毒軟體知道的特徵與行為已避開防毒軟體檢測
當本地無防毒軟體,流量不是很多等條件存在限制的情況下,可通過進算檔案Hash值,到一些網站利用Hash值進行查殺,原理以及常見的查詢平臺如下:
* 原理:雜湊值是一種獨特的演算法(雜湊函式)計算出檔案的唯一識別符號,不同檔案都不相同,影響因素可以是檔案大小,內容,建立日期等……計算出雜湊值,利用這些特性可以瞭解檔案沒有損壞或被修改也可用來在查詢平臺查詢分析結果。
* 計算工具:
Hasher Pro:http://www.den4b.com/
HashOnClick : https://www.2brightsparks.com
Hash Generator Pro:http://insili.co.uk/
MD5 File Hasher Pro:http://www.digital-tronic.com/md5-file-hasher/
Advanced Hash Calculator:http://www.filesweb.com/
* 查詢平臺:
微步雲沙箱:https://s.threatbook.cn/
Virus Toal:https://www.virustotal.com/gui/home/search
道高一尺魔高一丈
病毒未避免被靜態分析技術分析出來,常使用加殼、混淆技術,來躲避靜態分析
* 目的:躲避防毒軟體的檢測並增加病毒分析工作的難度
* 混淆:隱藏計算機病毒程式的資訊
* 常用工具:
DotFuscator:https://www.preemptive.com/
DashO Pro:https://www.preemptive.com/
ProGuard:https://www.guardsquare.com/en/proguard
Virbox Protector:https://shell.virbox.com/
Code Virtualizer:https://www.oreans.com/
Skater .NET obfuscator:http://www.rustemsoft.com/
* 加殼:壓縮計算機病毒檔案的大小,並使用加密技術保護病毒的核心程式碼
常用工具:
360加固保:https://jiagu.360.cn/
UPXShell:http://upxshell.sourceforge.net/download.html
DRMsoft EncryptEXE:http://www.drmsoft.com/
Vmproject:https://vmpsoft.com/
針對病毒的防護策略,常通過脫殼、反混淆技術來進行協助分析
* 脫殼:脫殼即去掉軟體所加的殼,軟體脫殼有手動脫和自動脫殼之分
常用工具:
QuickUnpack:http://qunpack.ahteam.org/?p=458#more-458
frida-unpack:https://github.com/WeiEast/frida-unpack
de4dot:https://github.com/0xd4d/de4dot
drizzleDumper:https://github.com/DrizzleRisk/drizzleDumper
de4js:https://github.com/lelinhtinh/de4js
wxappUnpacker:https://github.com/gzh4213/wxappUnpacker
Android_unpacker:https://github.com/CheckPointSW/android_unpacker
unpacker:https://github.com/malwaremusings/unpacker
* 反混淆:讓程式碼還原到美觀,高可讀性的狀態
常用工具:
simplify:https://github.com/CalebFenton/simplify
de4dot:https://github.com/0xd4d/de4dot
flare-floss:https://github.com/fireeye/flare-floss
Tigress_protection:https://github.com/JonathanSalwan/Tigress_protection
VTIL-Core:https://github.com/vtil-project/VTIL-Core
dex-oracle:https://github.com/CalebFenton/dex-oracle
malware-jail:https://github.com/HynekPetrak/malware-jail
de4js:https://github.com/lelinhtinh/de4js
dnpatch:https://github.com/ioncodes/dnpatch
etacsufbo:https://github.com/ChiChou/etacsufbo
samsung-firmware-magic:https://github.com/chrivers/samsung-firmware-magic
JRemapper:https://github.com/Col-E/JRemapper