用統計方法反推 JavaScript 壓縮程式的變數名稱

JavaScript 在正式提供服務時一般都會使用「YUI Compressor」、「UglifyJS」或是「Closure Compiler」壓縮後再拿到正式環境上使用,最主要的目的是為了降低網路傳輸量。

這些工具其中一個特點是,local function 與 local variable 會被較短的名字取代掉,這可以讓想要反組譯的人比較麻煩。

不過今天看到的這個工具可以解決「困擾」:「JSNice」。(在 Slashdot 上的「Machine Learning Used For JavaScript Code De-obfuscation」這篇看到的)

用統計方法去「猜測」這些 local function 與 local variable 應該叫什麼名字,讓人比較好理解。官方對準確度的說法是超過 60%:

In our experiments, we found JSNice to be effective for deobfuscating minified code. On average, more than 60% of the identifiers are recovered to the same name as before the minification process.

接下來會想辦法提供 UI 讓使用者可以選擇另外的名字:

Further, as JSNice computes multiple ranked suggestions, we provide a UI to navigate through these suggestions and select alternative identifier names.

先記錄起來,這網站很有趣,之後要 trace 別人的程式碼應該常常會用到 XDDD

Percona XtraDB Cluster 5.6 的第一個 RC 版本...

Percona XtraDB Cluster 5.6 的第一個 RC 版本公告出來了:「Percona XtraDB Cluster 5.6.15-25.2 first Release Candidate is now available」。

其他的說明沒什麼,但意外看到這點:

Percona XtraDB Cluster now supports stream compression/decompression with new xtrabackup-sst compressor/decompressor options.

在「option compressor/decompressor」這邊可以看到這個設定,功能是在傳輸 SST 的過程壓縮。

看了範例設定,似乎也可以使用 gzip 以外的方式?bzip2 或是 xz 應該是可行的方案?

對跨機房之間的 full resync 應該是有幫助的... 像是 IPsec 的處理能力沒那麼高的時候 :p

Perl 版本的 YUICompressor (CSS 的部份)

看到 Booking.comYUICompressor 移植到 Perl 上:「Efficient CSS Compression in Perl」。模組在 CSS::Compressor 這裡,看日期其實放出來蠻久的了?

開發的起因是因為 Java 啟動速度太慢,所以用 Perl 改寫... 雖然只能處理 CSS 的部份,但因為現在 JS 的主力應該是 UglifyJS2 或是 UglifyJS,理論上是可以把 Java 版本的 YUICompressor 了放到旁邊了?

據開發者自己的說法,因為 Java 啟動的 overhead 實在太重,就算是處理很大的 CSS 檔案,也可以省 40% 的時間,如果是小一點的檔案甚至可以省一半...