2012-05-17 72 views
1

我正在使用preg_match來查找和刪除文件中的eva64 base64編碼病毒。preg_match殺死頁面

正則表達式bewlow:

/\s*eval\s*\(\s*base64_decode\s*\(\s*('[a-zA-Z0-9\+\/]*={0,2}'|"[a-zA-Z0-9\+\/]*={0,2}")\s*\)\s*\s*\)\s*(;)?\s*/ 

下面的代碼匹配:

上述正則表達式工作正常。

我想匹配通過連接進行單詞包裝的base64字符串。所以它應該符合以下以及「BASE64 + EN」。 「已編碼+病毒+ HERE」。

所以我改變了正則表達式爲:

/\s*eval\s*\(\s*base64_decode\s*\(\s*\'([a-zA-Z0-9\+\/]*(\'\s*\.\s*\')?[a-zA-Z0-9\+\/]*)*={0,2}\'|"([a-zA-Z0-9\+\/]*("\s*\.\s*")?[a-zA-Z0-9\+\/]*)*={0,2}"\s*\)\s*\s*\)\s*(;)?\s*/ 

其中發現部分匹配爲:

"BASE64+ENCODED+VIRUS+HERE")); 

但是,當我嘗試應用這一整個文件比賽:http://pastebin.com/ED8sFUP0的頁面與死亡瀏覽器消息「加載頁面時重置了與服務器的連接。」

我有錯誤報告激活:

error_reporting(E_ALL); 
ini_set('display_errors', TRUE); 
ini_set('scream.enabled', TRUE); 

但沒有任何顯示了不在這裏,而不是在Apache的錯誤日誌。

在不包含有問題的字符串的文件上使用的正則表達式如預期的那樣工作; preg_match不返回布爾值false它返回0意味着沒有正則表達式錯誤,並且它沒有找到任何匹配。

我的擔心並不一定是爲什麼正則表達式只發現部分匹配。這可能是我發生這種情況的一種錯字。

我想,當知道和如何在正則表達式編譯失敗打破了整個工藝鏈

apache > php > regex_compiler 

我所知,這很可能是「因爲」我的正則表達式,只是碰巧編譯正確,但不匹配正確。這可能會導致一些不好的事情發生。但我的興趣是爲什麼正則表達式編譯器失敗,沒有錯誤,以及如何得到應該產生的錯誤消息。類似

事情進行了討論,但沒有解決此:php preg_match_all kills page for unknown reason

+0

我[回答了您鏈接的問題](http://stackoverflow.com/a/10643701/626273)。我認爲你有類似的問題,但我仍然試圖理解你的正則表達式。 – stema

回答

0

我覺得你的正則表達式有很多可能性,以匹配==>Catastrophic Backtracking

/\s*eval\s*\(\s*base64_decode\s*\(\s*\'([a-zA-Z0-9\+\/]*(\'\s*\.\s*\')?[a-zA-Z0-9\+\/]*)*={0,2}\'|"([a-zA-Z0-9\+\/]*("\s*\.\s*")?[a-zA-Z0-9\+\/]*)*={0,2}"\s*\)\s*\s*\)\s*(;)?\s*/ 
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

正則表達式將需要很多步驟,標誌着我==>你有性能問題的部分匹配,正則表達式就是不按時完成!

因爲(\'\s*\.\s*\')?是可選的,所以需要很多步驟,直到正則表達式找出與之前匹配的[a-zA-Z0-9\+\/]*以及可選部分之後的相同內容。

你可以做的就是使用possessive quantifiers(你通過在它後面加上一個+來量化所有格)。它們防止回溯,並且佔有量詞不會回饋它匹配的字符。所以,試試這個

/\s*eval\s*\(\s*base64_decode\s*\(\s*\'([a-zA-Z0-9\+\/]*+(\'\s*\.\s*\')?[a-zA-Z0-9\+\/]*+)*={0,2}\'|"([a-zA-Z0-9\+\/]*+("\s*\.\s*")?[a-zA-Z0-9\+\/]*+)*={0,2}"\s*\)\s*\s*\)\s*(;)?\s*/ 
                 ^^        ^^       ^^       ^^ 
+0

輝煌的伴侶,它確實解決了性能問題。我猜想它與我正在餵它的base64編碼病毒的260k文件有關。我只是沒有在「時間」域考慮它,我想到了它在內存領域。 –

+0

我曾想過使用[a-zA-z] *?對於一個懶惰的比賽(作爲一種表現增強),但是在我測試了它並且沒有發現變化之後,我忘記了回溯需要時間! –

1

編輯:

\s* 
eval \s* 
\(\s* 
    base64_decode \s* 
    \(\s* 
     (?: 
      (?> 
       ' 
       [a-zA-Z0-9+/]* 
       (?: 
        ' 
         \s* \. \s* 
        ' 
        [a-zA-Z0-9+/]* 
       )* 
       ={0,2} 
       ' 
      ) 
      | 
      (?> 
       " 
       [a-zA-Z0-9+/]* 
       (?: 
        " 
         \s* \. \s* 
        " 
        [a-zA-Z0-9+/]* 
       )* 
       ={0,2} 
       " 
      ) 
     ) 
     \s* 

    \)\s* 

\)\s* ;? \s* 

如何處理 「」 '' 連環

你不試圖解析語言(你不能這樣做這與此),所以你可以
處理連接條件"".''用這個非常快的正則表達式...

~ 
\s* 
eval \s* 
\(\s* 
    base64_decode 
    \s* 
    \(
     \s* 
     ["'] 
     (?> [a-zA-Z0-9+/]* (?: ["']\s*\.\s*["'] [a-zA-Z0-9+/]*)*) 
     ={0,2} 
     ["'] 
     \s* 
    \) 
    \s* 
\) 
\s* ;? \s* 

~x 
+0

這將會很有趣,@stema修復了整個表演的難度,你可能會修正一​​個精確度。我還沒有測試過你的解決方案。我的代碼基於eval + base64 + gzinflate/gzuncompress/bzdecompress + str_rot13的許多組合生成正則表達式,並且還考慮了隱藏在ascii-hexcodes/unicode-hexcode下的字符串。這些都讓您的解決方案變得困難。因此,我會在早上做這件事。 –

+0

由於你的代碼保留了性能問題,我的問題是「爲什麼我的正則表達式崩潰」,我想我會接受@ stema的「災難性回溯」答案。 –

+0

@Mihai Stancu - 沒問題,很高興你得到它的工作。我會想''[[a-zA-Z0-9 \ + \ /] *(\'\ s * \。\ s * \')?[a-zA-Z0-9 \ + \ /] *)*''到'[a-zA-Z0-9 + /] *(?:'\ s * \。\ s *'[a-zA-Z0-9 + /] *)*'也不會導致在FAIL上回溯很多。我把你的文件加載到2.4兆字節,在結尾處插入'='符號(但是無效)。花了1/2秒失敗,你剛掛了。所以我添加了原子分組,現在需要1/4秒才能失敗。代碼在我的編輯。我也發佈了你的正則表達式擴展和一個問題。 - 祝你好運! – sln